Privacy-preserving distributed visual data processing

ABSTRACT

In one embodiment, an apparatus comprises a processor to: identify a workload comprising a plurality of tasks; generate a workload graph based on the workload, wherein the workload graph comprises information associated with the plurality of tasks; identify a device connectivity graph, wherein the device connectivity graph comprises device connectivity information associated with a plurality of processing devices; identify a privacy policy associated with the workload; identify privacy level information associated with the plurality of processing devices; identify a privacy constraint based on the privacy policy and the privacy level information; and determine a workload schedule, wherein the workload schedule comprises a mapping of the workload onto the plurality of processing devices, and wherein the workload schedule is determined based on the privacy constraint, the workload graph, and the device connectivity graph. The apparatus further comprises a communication interface to send the workload schedule to the plurality of processing devices.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation (and claims the benefit under35 U.S.C. § 120) of U.S. application Ser. No. 15/859,324, filed Dec. 29,2017, which claims the benefit of the filing date of U.S. ProvisionalPatent Application Ser. No. 62/611,536, filed on Dec. 28, 2017, andentitled “VISUAL FOG,” the content of which is hereby expresslyincorporated by reference.

FIELD OF THE SPECIFICATION

This disclosure relates in general to the field of computing systems,and more particularly, though not exclusively, to visual computing.

BACKGROUND

Advancements in modern computing have led to an increased use of visualcomputing for a variety of mainstream computing applications. Inparticular, rapid deployments of cameras have been leveraged fornumerous visual computing applications that rely on large-scale videoanalytics and visual data processing. Existing approaches to large-scalevisual computing, however, suffer from numerous limitations. Forexample, existing visual computing approaches are implemented usingrigid designs that utilize resources inefficiently and provide limitedfunctionality, privacy, and security. As a result, existing approachesoften suffer from high latency and are inaccurate, unreliable,inflexible, and incapable of scaling efficiently.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is best understood from the following detaileddescription when read with the accompanying figures. It is emphasizedthat, in accordance with the standard practice in the industry, variousfeatures are not necessarily drawn to scale, and are used forillustration purposes only. Where a scale is shown, explicitly orimplicitly, it provides only one illustrative example. In otherembodiments, the dimensions of the various features may be arbitrarilyincreased or reduced for clarity of discussion.

FIG. 1 illustrates an example embodiment of a visual fog system inaccordance with certain embodiments.

FIGS. 2, 3, 4, and 5 illustrate examples of Internet-of-Things (IoT)networks and architectures that can be used in accordance with certainembodiments.

FIGS. 6 and 7 illustrate example computer architectures that can be usedin accordance with certain embodiments.

FIG. 8 illustrates an example embodiment of an architecture for visualfog nodes.

FIGS. 9, 10, 11, and 12A-B illustrate example embodiments of a visualfog architecture.

FIGS. 13 and 14 illustrate example embodiments associated with a visualquestion answering (VQA) framework.

FIGS. 15 and 16 illustrate example embodiments of device-centricscheduling for visual fog computing.

FIG. 17 illustrates an example embodiment of a runtime processingpipeline for a visual fog architecture.

FIG. 18 illustrates an example embodiment of a visual data storagearchitecture.

FIG. 19 illustrates an example of a vision processing pipeline thatleverages metadata for searching visual data.

FIGS. 20 and 21 illustrate examples of representing visual metadatausing a property graph.

FIG. 22 illustrates an example embodiment of an analytic image formatdesigned to aid in visual data processing.

FIG. 23 illustrates a performance graph for various image formats.

FIGS. 24A, 24B, and 24C illustrate an example embodiment of amulti-domain cascade convolutional neural network (CNN).

FIGS. 25A-B, 26, 27, 28, 29, 30, and 31A-B illustrate the use ofbutterfly operations for a multi-domain convolutional neural network(CNN).

FIGS. 32 and 33 illustrate an example embodiment of a three-dimensional(3D) CNN for processing compressed visual data.

FIG. 34 illustrates an example of a pixel-domain CNN.

FIG. 35 illustrates an example of a pixel-domain visual analyticspipeline.

FIGS. 36 and 37 illustrate example embodiments of compressed-domainvisual analytics pipelines.

FIG. 38 illustrates a performance graph showing the precision of a CNNtrained using compressed visual data.

FIG. 39 illustrates a flowchart for an example embodiment ofcontext-aware image compression.

FIGS. 40A, 40B, and 40C illustrate an example embodiment of aprivacy-preserving demographic identification system.

FIGS. 41, 42, and 43 illustrate an example embodiment ofprivacy-preserving distributed visual data processing.

FIGS. 44, 45, and 46 illustrate example embodiments of self-sovereigndevice identification for distributed computing networks.

FIG. 47 illustrates an example of device onboarding/commissioning in avisual fog network without conflict resolution.

FIGS. 48 and 49 illustrate example embodiments of algorithmidentification for distributed computing using a self-sovereignblockchain.

FIGS. 50, 51, and 52 illustrate example embodiments for processingtraditional and analytic image formats.

FIG. 53 illustrates a flowchart for an example embodiment ofprivacy-preserving demographics identification.

FIG. 54 illustrates a flowchart for an example embodiment ofprivacy-preserving distributed visual processing.

EMBODIMENTS OF THE DISCLOSURE

This patent application claims the benefit of the filing date of U.S.Provisional Patent Application Ser. No. 62/611,536, filed on Dec. 28,2017, and entitled “VISUAL FOG,” the content of which is herebyexpressly incorporated by reference.

The following disclosure provides many different embodiments, orexamples, for implementing different features of the present disclosure.Specific examples of components and arrangements are described below tosimplify the present disclosure. These are, of course, merely examplesand are not intended to be limiting. Further, the present disclosure mayrepeat reference numerals and/or letters in the various examples. Thisrepetition is for the purpose of simplicity and clarity and does not initself dictate a relationship between the various embodiments and/orconfigurations discussed. Different embodiments may have differentadvantages, and no particular advantage is necessarily required of anyembodiment.

Example embodiments that may be used to implement the features andfunctionality of this disclosure will now be described with moreparticular reference to the attached FIGURES.

Visual Fog Introduction

FIG. 1 illustrates an example embodiment of a visual fog system 100 inaccordance with certain embodiments. Advancements in modern computinghave led to an increased use of computer vision technologies andlarge-scale visual computing for a variety of mainstream computingapplications. In particular, rapid deployments of cameras and othertypes of computer vision technologies have been leveraged for a varietyof visual computing applications that rely on large-scale videoanalytics and visual data processing. For example, large-scale visualcomputing can be leveraged for security and surveillance, transportation(e.g., traffic monitoring, navigation, parking, infrastructure planning,security or amber alerts), retail (e.g., customer analytics), enterpriseapplications, and so forth.

Existing approaches to large-scale visual computing, however, sufferfrom numerous limitations. In particular, existing visual computingapproaches are implemented using rigid designs that utilize resourcesinefficiently (e.g., processing, bandwidth, and storage resources) andprovide limited functionality. For example, using existing approaches,visual data is typically captured by devices at the edge of a networkand simply funneled to the cloud for processing and storage, thusrelying heavily on the cloud infrastructure. Due to the large size ofvisual data, however, this approach typically consumes significantnetwork bandwidth and requires substantial processing and storageresources in the cloud. As a result, existing approaches often sufferfrom high latency and inefficient resource utilization, and may also beinaccurate, unreliable, inflexible, and incapable of scalingefficiently.

Accordingly, this disclosure describes various embodiments of a visualfog computing system 100 for performing large-scale visual computing inan efficient and reliable manner. For example, rather than relyingexclusively or primarily on cloud resources 130 for visual computingtasks, visual fog system 100 leverages both cloud 130 and edge 110resources, which may be collectively referred to as the “fog.” In thismanner, visual fog system 100 can leverage all available “fog” resourcesto perform visual computing tasks more efficiently, thus improvingresource utilization, latency, accuracy, precision, and reliability.Moreover, as described further throughout this disclosure, visual fogsystem 100 can be implemented using a flexible design that supportsad-hoc queries and is highly scalable, thus rendering it suitable formany visual computing applications and use cases.

In the illustrated embodiment of FIG. 1, visual fog system 100 includesedge resources 110 and a plurality of associated visual sensors 120,cloud resources 130, and communication networks 150, which arerespectively discussed further below. Moreover, in various embodiments,these components of visual fog system 100 may be implemented some or allaspects of the visual computing functionality described throughout thisdisclosure in connection with the remaining FIGURES.

Edge resources 110 may include any equipment, devices, and/or componentsdeployed or connected near the “edge” of a communication network. In theillustrated embodiment, for example, edge resources 110 include end-userdevices 112 a,b (e.g., desktops, laptops, mobile devices),Internet-of-Things (IoT) devices 114, and gateways or routers 116, asdescribed further below. Edge resources 110 may communicate with eachother and/or with other remote networks and resources (e.g., cloudresources 130) through one or more communication networks 150, such aslocal area network 150 a and/or wide area network 150 b. Moreover, inthe illustrated embodiment, edge resources 110 collectively include aplurality of visual sensors 120 (e.g., cameras) for capturing visualrepresentations and data associated with their surroundings. In someembodiments, for example, certain end-user devices 112 and/or IoTdevices 114 may include one or more cameras and/or other types of visualsensors 120. Visual sensors 120 may include any type of visual oroptical sensors, such as cameras, ultraviolet (UV) sensors, laserrangefinders (e.g., light detection and ranging (LIDAR)), infrared (IR)sensors, electro-optical/infrared (EO/IR) sensors, and so forth.

End-user devices 112 may include any device that enables or facilitatesinteraction with a user in visual fog system 100, including, forexample, desktop computers, laptops, tablets, mobile phones and othermobile devices, and wearable devices (e.g., smart watches, smartglasses, headsets), among other examples.

IoT devices 114 may include any device capable of communicating and/orparticipating in an Internet-of-Things (IoT) system or network. IoTsystems may refer to new or improved ad-hoc systems and networkscomposed of a variety of different devices (e.g., IoT devices 114)interoperating and synergizing for a particular application or use case.Such ad-hoc systems are emerging as more and more products and equipmentevolve to become “smart,” meaning they are controlled or monitored bycomputer processors and are capable of communicating with other devices.For example, an IoT device 114 may include a computer processor and/orcommunication interface to allow interoperation with other components ofvisual fog system 100, such as with cloud resources 130 and/or otheredge resources 110. IoT devices 114 may be “greenfield” devices that aredeveloped with IoT capabilities from the ground-up, or “brownfield”devices that are created by integrating IoT capabilities into existinglegacy devices that were initially developed without IoT capabilities.For example, in some cases, IoT devices 114 may be built from sensorsand communication modules integrated in or attached to “things,” such asequipment, toys, tools, vehicles, living things (e.g., plants, animals,humans), and so forth. Alternatively, or additionally, certain IoTdevices 114 may rely on intermediary components, such as edge gatewaysor routers 116, to communicate with the various components of system100.

IoT devices 114 may include various types of sensors for monitoring,detecting, measuring, and generating sensor data and signals associatedwith characteristics of their environment. In some embodiments, forexample, certain IoT devices 114 may include visual sensors 120 (e.g.,cameras) for capturing visual representations and data associated withtheir surroundings. IoT devices 114 may also include other types ofsensors configured to detect characteristics such as movement, weight,physical contact, temperature, wind, noise, light, position, humidity,radiation, liquid, specific chemical compounds, battery life, wirelesssignals, computer communications, and bandwidth, among other examples.Sensors can include physical sensors (e.g., physical monitoringcomponents) and virtual sensors (e.g., software-based monitoringcomponents). IoT devices 114 may also include actuators to performvarious actions in their respective environments. For example, anactuator may be used to selectively activate certain functionality, suchas toggling the power or operation of a security system (e.g., alarm,camera, locks) or household appliance (e.g., audio system, lighting,HVAC appliances, garage doors), among other examples.

Indeed, this disclosure contemplates use of a potentially limitlessuniverse of IoT devices 114 and associated sensors/actuators. IoTdevices 114 may include, for example, any type of equipment and/ordevices associated with any type of system 100 and/or industry,including transportation (e.g., automobile, airlines), industrialmanufacturing, energy (e.g., power plants), telecommunications (e.g.,Internet, cellular, and television service providers), retail, medical(e.g., healthcare, pharmaceutical), and/or food and beverage, amongothers. In the transportation industry, for example, IoT devices 114 mayinclude equipment and devices associated with aircrafts, automobiles, orvessels, such as navigation systems, autonomous flight or drivingsystems, traffic monitoring and/or planning systems, parking systems,and/or any internal mechanical or electrical components that aremonitored by sensors (e.g., engines). IoT devices 114 may also includeequipment, devices, and/or infrastructure associated with industrialmanufacturing and production, shipping (e.g., cargo tracking),communications networks (e.g., gateways, routers, servers, cellulartowers), server farms, electrical power plants, wind farms, oil and gaspipelines, water treatment and distribution, wastewater collection andtreatment, and weather monitoring (e.g., temperature, wind, and humiditysensors), among other examples. IoT devices 114 may also include, forexample, any type of “smart” device or system, such as smartentertainment systems (e.g., televisions, audio systems, videogamesystems), smart household or office appliances (e.g.,heat-ventilation-air-conditioning (HVAC) appliances, refrigerators,washers and dryers, coffee brewers), power control systems (e.g.,automatic electricity, light, and HVAC controls), security systems(e.g., alarms, locks, cameras, motion detectors, fingerprint scanners,facial recognition systems), and other home automation systems, amongother examples. IoT devices 114 can be statically located, such asmounted on a building, wall, floor, ground, lamppost, sign, water tower,or any other fixed or static structure. IoT devices 114 can also bemobile, such as devices in vehicles or aircrafts, drones, packages(e.g., for tracking cargo), mobile devices, and wearable devices, amongother examples. Moreover, any type of edge resource 110 may also beconsidered as an IoT device 114, including end-user devices 112 and edgegateways 116, among other examples.

Edge gateways and/or routers 116 may be used to facilitate communicationto and from edge resources 110. For example, gateways 116 may providecommunication capabilities to existing legacy devices that wereinitially developed without any such capabilities (e.g., “brownfield”IoT devices 114). Gateways 116 can also be utilized to extend thegeographical reach of edge resources 110 with short-range, proprietary,or otherwise limited communication capabilities, such as IoT devices 114with Bluetooth or ZigBee communication capabilities. For example,gateways 116 can serve as intermediaries between IoT devices 114 andremote networks or services, by providing a front-haul to the IoTdevices 114 using their native communication capabilities (e.g.,Bluetooth, ZigBee), and providing a back-haul to other networks 150and/or cloud resources 130 using another wired or wireless communicationmedium (e.g., Ethernet, Wi-Fi, cellular). In some embodiments, a gateway116 may be implemented by a dedicated gateway device, or by ageneral-purpose device, such as another IoT device 114, end-user device112, or other type of edge resource 110. In some instances, gateways 116may also implement certain network management and/or applicationfunctionality (e.g., visual computing functionality, IoT application andmanagement functionality), either separately or in conjunction withother components, such as cloud resources 130 and/or other edgeresources 110.

Cloud resources 130 may include any resources or services that arehosted remotely over a network, which may otherwise be referred to as inthe “cloud.” In some embodiments, for example, cloud resources 130 maybe remotely hosted on servers in a datacenter (e.g., applicationservers, database servers). Cloud resources 130 may include anyresources, services, and/or functionality that can be utilized by or foredge resources 110, including but not limited to, visual computingapplications and services, IoT application and management services, datastorage, computational services (e.g., data analytics, searching,diagnostics and fault management), security services (e.g.,surveillance, alarms, user authentication), mapping and navigation,geolocation services, network or infrastructure management, paymentprocessing, audio and video streaming, messaging, social networking,news, and weather, among other examples.

Communication networks 150 a,b may be used to facilitate communicationbetween components of system 100. In the illustrated embodiment, forexample, edge resources 110 are connected to local area network (LAN)150 a in order to facilitate communication with each other and/or otherremote networks or resources, such as wide area network (WAN) 150 band/or cloud resources 130. In various embodiments, visual fog system100 may be implemented using any number or type of communicationnetwork(s) 150, including local area networks, wide area networks,public networks, the Internet, cellular networks, Wi-Fi networks,short-range networks (e.g., Bluetooth or ZigBee), and/or any other wiredor wireless communication networks or mediums.

In general, edge resources 110 (and in particular IoT devices 114) maygenerate an extremely large volume and variety of data. As one example,edge resources 110 with visual sensors 120 may generate large volumes ofvisual data, such as video and/or images. Edge resources 110 typicallyoffload this data to the cloud 130 for processing and/or storage. Cloudresources 130, however, may not necessarily be suited to handle therapidly growing volume, variety, and velocity of data generated by IoTdevices 114 and other edge resources 110. For example, cloud-basedprocessing may not be ideal in certain circumstances, such as processingtime-sensitive or highly confidential data, or when faced with networkbandwidth constraints, among other examples. Accordingly, in someembodiments, visual fog system 100 may leverage “edge” processing toaugment the performance and capabilities of the cloud 130 using edgeresources 110. Edge processing is an approach that involves processingcertain data at the network edge (e.g., using edge resources 110), nearwhere the data is generated, rather than simply funneling large volumesof data to the cloud for processing and storage. Certain data may stillbe sent to the cloud, as appropriate, such as for deeper analysis and/orlong-term storage. Edge processing may be used to complement theshortcomings of cloud-based processing (e.g., when cloud-basedprocessing is inefficient, ineffective, and/or unsecure), and thusimprove the handling of the growing volume, variety, and velocity ofdata generated by IoT devices 114 and/or other edge resources 110. Forexample, in some cases, processing data near its source (e.g., in thenetwork edge) rather than in the cloud may improve performance and/oravoid system failures or disasters. Edge processing may also conservenetwork bandwidth, which may be particularly beneficial when facingbandwidth constraints and/or limited network connectivity.

In some cases, the collective use of both edge 110 and cloud 130resources may be referred to as “fog” computing, as functionality of the“cloud” 130 is effectively extended by the edge resources 110, thusforming a “fog” over the network edge. Moreover, in some embodiments,devices 110 in the “fog” may connect and/or communicate with each otherusing an interconnection standard or protocol, such as the openinterconnect consortium (OIC) standard specification 1.0, released bythe Open Connectivity Foundation™ (OCF) on Dec. 23, 2015, which enablesdevices to discover and connect with each other; Thread, a networkingprotocol for Internet-of-Things (IoT) devices used in “smart” homeautomation and similar deployments, developed by an alliance oforganizations named the “Thread Group”; the optimized link state routing(OLSR) protocol; and/or the better approach to mobile ad-hoc networking(B.A.T.M.A.N.), among other examples.

Moreover, in some embodiments, fog computing may be leveraged by visualfog system 100 for large-scale visual computing applications. Forexample, in some embodiments, the components of visual fog system 100(e.g., edge resources 110, cloud resources 130) may be implemented withsome or all aspects of the visual computing functionality describedthroughout this disclosure in connection with the remaining FIGURES.

Any, all, or some of the computing devices of system 100 may be adaptedto execute any operating system, including Linux or other UNIX-basedoperating systems, Microsoft Windows, Windows Server, MacOS, Apple iOS,Google Android, or any customized and/or proprietary operating system,along with virtual machines adapted to virtualize execution of aparticular operating system.

While FIG. 1 is described as containing or being associated with aplurality of elements, not all elements illustrated within system 100 ofFIG. 1 may be utilized in each alternative implementation of the presentdisclosure. Additionally, one or more of the elements described inconnection with the examples of FIG. 1 may be located external to system100, while in other instances, certain elements may be included withinor as a portion of one or more of the other described elements, as wellas other elements not described in the illustrated implementation.Further, certain elements illustrated in FIG. 1 may be combined withother components, as well as used for alternative or additional purposesin addition to those purposes described herein.

Additional embodiments associated with the implementation of a visualfog computing system 100 are described further in connection with theremaining FIGURES. Accordingly, it should be appreciated that visual fogsystem 100 of FIG. 1 may be implemented with any aspects of theembodiments described throughout this disclosure.

Example Internet-of-Things (IoT) Implementations

FIGS. 2-5 illustrate examples of Internet-of-Things (IoT) networks anddevices that can be used in accordance with embodiments disclosedherein. For example, the operations and functionality describedthroughout this disclosure may be embodied by an IoT device or machinein the example form of an electronic processing system, within which aset or sequence of instructions may be executed to cause the electronicprocessing system to perform any one of the methodologies discussedherein, according to an example embodiment. The machine may be an IoTdevice or an IoT gateway, including a machine embodied by aspects of apersonal computer (PC), a tablet PC, a personal digital assistant (PDA),a mobile telephone or smartphone, or any machine capable of executinginstructions (sequential or otherwise) that specify actions to be takenby that machine. Further, while only a single machine may be depictedand referenced in the example above, such machine shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein. Further, these and like examples toa processor-based system shall be taken to include any set of one ormore machines that are controlled by or operated by a processor (e.g., acomputer) to individually or jointly execute instructions to perform anyone or more of the methodologies discussed herein.

FIG. 2 illustrates an example domain topology for respectiveinternet-of-things (IoT) networks coupled through links to respectivegateways. The internet of things (IoT) is a concept in which a largenumber of computing devices are interconnected to each other and to theInternet to provide functionality and data acquisition at very lowlevels. Thus, as used herein, an IoT device may include a semiautonomousdevice performing a function, such as sensing or control, among others,in communication with other IoT devices and a wider network, such as theInternet.

Often, IoT devices are limited in memory, size, or functionality,allowing larger numbers to be deployed for a similar cost to smallernumbers of larger devices. However, an IoT device may be a smart phone,laptop, tablet, or PC, or other larger device. Further, an IoT devicemay be a virtual device, such as an application on a smart phone orother computing device. IoT devices may include IoT gateways, used tocouple IoT devices to other IoT devices and to cloud applications, fordata storage, process control, and the like.

Networks of IoT devices may include commercial and home automationdevices, such as water distribution systems, electric power distributionsystems, pipeline control systems, plant control systems, lightswitches, thermostats, locks, cameras, alarms, motion sensors, and thelike. The IoT devices may be accessible through remote computers,servers, and other systems, for example, to control systems or accessdata.

The future growth of the Internet and like networks may involve verylarge numbers of IoT devices. Accordingly, in the context of thetechniques discussed herein, a number of innovations for such futurenetworking will address the need for all these layers to growunhindered, to discover and make accessible connected resources, and tosupport the ability to hide and compartmentalize connected resources.Any number of network protocols and communications standards may beused, wherein each protocol and standard is designed to address specificobjectives. Further, the protocols are part of the fabric supportinghuman accessible services that operate regardless of location, time orspace. The innovations include service delivery and associatedinfrastructure, such as hardware and software; security enhancements;and the provision of services based on Quality of Service (QoS) termsspecified in service level and service delivery agreements. As will beunderstood, the use of IoT devices and networks, such as thoseintroduced in FIGS. 2-5, present a number of new challenges in aheterogeneous network of connectivity comprising a combination of wiredand wireless technologies.

FIG. 2 specifically provides a simplified drawing of a domain topologythat may be used for a number of internet-of-things (IoT) networkscomprising IoT devices 204, with the IoT networks 256, 258, 260, 262,coupled through backbone links 202 to respective gateways 254. Forexample, a number of IoT devices 204 may communicate with a gateway 254,and with each other through the gateway 254. To simplify the drawing,not every IoT device 204, or communications link (e.g., link 216, 222,228, or 232) is labeled. The backbone links 202 may include any numberof wired or wireless technologies, including optical networks, and maybe part of a local area network (LAN), a wide area network (WAN), or theInternet. Additionally, such communication links facilitate opticalsignal paths among both IoT devices 204 and gateways 254, including theuse of MUXing/deMUXing components that facilitate interconnection of thevarious devices.

The network topology may include any number of types of IoT networks,such as a mesh network provided with the network 256 using Bluetooth lowenergy (BLE) links 222. Other types of IoT networks that may be presentinclude a wireless local area network (WLAN) network 258 used tocommunicate with IoT devices 204 through IEEE 802.11 (Wi-Fi®) links 228,a cellular network 260 used to communicate with IoT devices 204 throughan LTE/LTE-A (4G) or 5G cellular network, and a low-power wide area(LPWA) network 262, for example, a LPWA network compatible with theLoRaWan specification promulgated by the LoRa alliance, or a IPv6 overLow Power Wide-Area Networks (LPWAN) network compatible with aspecification promulgated by the Internet Engineering Task Force (IETF).Further, the respective IoT networks may communicate with an outsidenetwork provider (e.g., a tier 2 or tier 3 provider) using any number ofcommunications links, such as an LTE cellular link, an LPWA link, or alink based on the IEEE 802.15.4 standard, such as Zigbee. The respectiveIoT networks may also operate with use of a variety of network andinternet application protocols such as Constrained Application Protocol(CoAP). The respective IoT networks may also be integrated withcoordinator devices that provide a chain of links that forms clustertree of linked devices and networks.

Each of these IoT networks may provide opportunities for new technicalfeatures, such as those as described herein. The improved technologiesand networks may enable the exponential growth of devices and networks,including the use of IoT networks into as fog devices or systems. As theuse of such improved technologies grows, the IoT networks may bedeveloped for self-management, functional evolution, and collaboration,without needing direct human intervention. The improved technologies mayeven enable IoT networks to function without centralized controlledsystems. Accordingly, the improved technologies described herein may beused to automate and enhance network management and operation functionsfar beyond current implementations.

In an example, communications between IoT devices 204, such as over thebackbone links 202, may be protected by a decentralized system forauthentication, authorization, and accounting (AAA). In a decentralizedAAA system, distributed payment, credit, audit, authorization, andauthentication systems may be implemented across interconnectedheterogeneous network infrastructure. This allows systems and networksto move towards autonomous operations. In these types of autonomousoperations, machines may even contract for human resources and negotiatepartnerships with other machine networks. This may allow the achievementof mutual objectives and balanced service delivery against outlined,planned service level agreements as well as achieve solutions thatprovide metering, measurements, traceability and trackability. Thecreation of new supply chain structures and methods may enable amultitude of services to be created, mined for value, and collapsedwithout any human involvement.

Such IoT networks may be further enhanced by the integration of sensingtechnologies, such as sound, light, electronic traffic, facial andpattern recognition, smell, vibration, into the autonomous organizationsamong the IoT devices. The integration of sensory systems may allowsystematic and autonomous communication and coordination of servicedelivery against contractual service objectives, orchestration andquality of service (QoS) based swarming and fusion of resources. Some ofthe individual examples of network-based resource processing include thefollowing.

The mesh network 256, for instance, may be enhanced by systems thatperform inline data-to-information transforms. For example, self-formingchains of processing resources comprising a multi-link network maydistribute the transformation of raw data to information in an efficientmanner, and the ability to differentiate between assets and resourcesand the associated management of each. Furthermore, the propercomponents of infrastructure and resource based trust and serviceindices may be inserted to improve the data integrity, quality,assurance and deliver a metric of data confidence.

The WLAN network 258, for instance, may use systems that performstandards conversion to provide multi-standard connectivity, enablingIoT devices 204 using different protocols to communicate. Furthersystems may provide seamless interconnectivity across a multi-standardinfrastructure comprising visible Internet resources and hidden Internetresources.

Communications in the cellular network 260, for instance, may beenhanced by systems that offload data, extend communications to moreremote devices, or both. The LPWA network 262 may include systems thatperform non-Internet protocol (IP) to IP interconnections, addressing,and routing. Further, each of the IoT devices 204 may include theappropriate transceiver for wide area communications with that device.Further, each IoT device 204 may include other transceivers forcommunications using additional protocols and frequencies.

Finally, clusters of IoT devices may be equipped to communicate withother IoT devices as well as with a cloud network. This may allow theIoT devices to form an ad-hoc network between the devices, allowing themto function as a single device, which may be termed a fog device. Thisconfiguration is discussed further with respect to FIG. 3 below.

FIG. 3 illustrates a cloud computing network in communication with amesh network of IoT devices (devices 302) operating as a fog device atthe edge of the cloud computing network. The mesh network of IoT devicesmay be termed a fog 320, operating at the edge of the cloud 300. Tosimplify the diagram, not every IoT device 302 is labeled.

The fog 320 may be considered to be a massively interconnected networkwherein a number of IoT devices 302 are in communications with eachother, for example, by radio links 322. As an example, thisinterconnected network may be facilitated using an interconnectspecification released by the Open Connectivity Foundation™ (OCF). Thisstandard allows devices to discover each other and establishcommunications for interconnects. Other interconnection protocols mayalso be used, including, for example, the optimized link state routing(OLSR) Protocol, the better approach to mobile ad-hoc networking(B.A.T.M.A.N.) routing protocol, or the OMA Lightweight M2M (LWM2M)protocol, among others.

Three types of IoT devices 302 are shown in this example, gateways 304,data aggregators 326, and sensors 328, although any combinations of IoTdevices 302 and functionality may be used. The gateways 304 may be edgedevices that provide communications between the cloud 300 and the fog320, and may also provide the backend process function for data obtainedfrom sensors 328, such as motion data, flow data, temperature data, andthe like. The data aggregators 326 may collect data from any number ofthe sensors 328, and perform the back-end processing function for theanalysis. The results, raw data, or both may be passed along to thecloud 300 through the gateways 304. The sensors 328 may be full IoTdevices 302, for example, capable of both collecting data and processingthe data. In some cases, the sensors 328 may be more limited infunctionality, for example, collecting the data and allowing the dataaggregators 326 or gateways 304 to process the data.

Communications from any IoT device 302 may be passed along a convenientpath (e.g., a most convenient path) between any of the IoT devices 302to reach the gateways 304. In these networks, the number ofinterconnections provide substantial redundancy, allowing communicationsto be maintained, even with the loss of a number of IoT devices 302.Further, the use of a mesh network may allow IoT devices 302 that arevery low power or located at a distance from infrastructure to be used,as the range to connect to another IoT device 302 may be much less thanthe range to connect to the gateways 304.

The fog 320 provided from these IoT devices 302 may be presented todevices in the cloud 300, such as a server 306, as a single devicelocated at the edge of the cloud 300, e.g., a fog device. In thisexample, the alerts coming from the fog device may be sent without beingidentified as coming from a specific IoT device 302 within the fog 320.In this fashion, the fog 320 may be considered a distributed platformthat provides computing and storage resources to perform processing ordata-intensive tasks such as data analytics, data aggregation, andmachine-learning, among others.

In some examples, the IoT devices 302 may be configured using animperative programming style, e.g., with each IoT device 302 having aspecific function and communication partners. However, the IoT devices302 forming the fog device may be configured in a declarativeprogramming style, allowing the IoT devices 302 to reconfigure theiroperations and communications, such as to determine needed resources inresponse to conditions, queries, and device failures. As an example, aquery from a user located at a server 306 about the operations of asubset of equipment monitored by the IoT devices 302 may result in thefog 320 device selecting the IoT devices 302, such as particular sensors328, needed to answer the query. The data from these sensors 328 maythen be aggregated and analyzed by any combination of the sensors 328,data aggregators 326, or gateways 304, before being sent on by the fog320 device to the server 306 to answer the query. In this example, IoTdevices 302 in the fog 320 may select the sensors 328 used based on thequery, such as adding data from flow sensors or temperature sensors.Further, if some of the IoT devices 302 are not operational, other IoTdevices 302 in the fog 320 device may provide analogous data, ifavailable.

FIG. 4 illustrates a drawing of a cloud computing network, or cloud 400,in communication with a number of Internet of Things (IoT) devices. Thecloud 400 may represent the Internet, or may be a local area network(LAN), or a wide area network (WAN), such as a proprietary network for acompany. The IoT devices may include any number of different types ofdevices, grouped in various combinations. For example, a traffic controlgroup 406 may include IoT devices along streets in a city. These IoTdevices may include stoplights, traffic flow monitors, cameras, weathersensors, and the like. The traffic control group 406, or othersubgroups, may be in communication with the cloud 400 through wired orwireless links 408, such as LPWA links, optical links, and the like.Further, a wired or wireless sub-network 412 may allow the IoT devicesto communicate with each other, such as through a local area network, awireless local area network, and the like. The IoT devices may useanother device, such as a gateway 510 or 528 to communicate with remotelocations such as the cloud 500; the IoT devices may also use one ormore servers 530 to facilitate communication with the cloud 500 or withthe gateway 510. For example, the one or more servers 530 may operate asan intermediate network node to support a local edge cloud or fogimplementation among a local area network. Further, the gateway 528 thatis depicted may operate in a cloud-to-gateway-to-many edge devicesconfiguration, such as with the various IoT devices 514, 520, 524 beingconstrained or dynamic to an assignment and use of resources in thecloud 500.

Other example groups of IoT devices may include remote weather stations414, local information terminals 416, alarm systems 418, automatedteller machines 420, alarm panels 422, or moving vehicles, such asemergency vehicles 424 or other vehicles 426, among many others. Each ofthese IoT devices may be in communication with other IoT devices, withservers 404, with another IoT fog device or system (not shown, butdepicted in FIG. 3), or a combination therein. The groups of IoT devicesmay be deployed in various residential, commercial, and industrialsettings (including in both private or public environments).

As can be seen from FIG. 4, a large number of IoT devices may becommunicating through the cloud 400. This may allow different IoTdevices to request or provide information to other devices autonomously.For example, a group of IoT devices (e.g., the traffic control group406) may request a current weather forecast from a group of remoteweather stations 414, which may provide the forecast without humanintervention. Further, an emergency vehicle 424 may be alerted by anautomated teller machine 420 that a burglary is in progress. As theemergency vehicle 424 proceeds towards the automated teller machine 420,it may access the traffic control group 406 to request clearance to thelocation, for example, by lights turning red to block cross traffic atan intersection in sufficient time for the emergency vehicle 424 to haveunimpeded access to the intersection.

Clusters of IoT devices, such as the remote weather stations 414 or thetraffic control group 406, may be equipped to communicate with other IoTdevices as well as with the cloud 400. This may allow the IoT devices toform an ad-hoc network between the devices, allowing them to function asa single device, which may be termed a fog device or system (e.g., asdescribed above with reference to FIG. 3).

FIG. 5 is a block diagram of an example of components that may bepresent in an IoT device 550 for implementing the techniques describedherein. The IoT device 550 may include any combinations of thecomponents shown in the example or referenced in the disclosure above.The components may be implemented as ICs, portions thereof, discreteelectronic devices, or other modules, logic, hardware, software,firmware, or a combination thereof adapted in the IoT device 550, or ascomponents otherwise incorporated within a chassis of a larger system.Additionally, the block diagram of FIG. 5 is intended to depict ahigh-level view of components of the IoT device 550. However, some ofthe components shown may be omitted, additional components may bepresent, and different arrangement of the components shown may occur inother implementations.

The IoT device 550 may include a processor 552, which may be amicroprocessor, a multi-core processor, a multithreaded processor, anultra-low voltage processor, an embedded processor, or other knownprocessing element. The processor 552 may be a part of a system on achip (SoC) in which the processor 552 and other components are formedinto a single integrated circuit, or a single package, such as theEdison™ or Galileo™ SoC boards from Intel. As an example, the processor552 may include an Intel® Architecture Core™ based processor, such as aQuark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, oranother such processor available from Intel® Corporation, Santa Clara,Calif. However, any number other processors may be used, such asavailable from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, Calif.,a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, Calif.,an ARM-based design licensed from ARM Holdings, Ltd. or customerthereof, or their licensees or adopters. The processors may includeunits such as an A5-A10 processor from Apple® Inc., a Snapdragon™processor from Qualcomm® Technologies, Inc., or an OMAP™ processor fromTexas Instruments, Inc.

The processor 552 may communicate with a system memory 554 over aninterconnect 556 (e.g., a bus). Any number of memory devices may be usedto provide for a given amount of system memory. As examples, the memorymay be random access memory (RAM) in accordance with a Joint ElectronDevices Engineering Council (JEDEC) design such as the DDR or mobile DDRstandards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In variousimplementations, the individual memory devices may be of any number ofdifferent package types such as single die package (SDP), dual diepackage (DDP) or quad die package (Q17P). These devices, in someexamples, may be directly soldered onto a motherboard to provide a lowerprofile solution, while in other examples the devices are configured asone or more memory modules that in turn couple to the motherboard by agiven connector. Any number of other memory implementations may be used,such as other types of memory modules, e.g., dual inline memory modules(DIMMs) of different varieties including but not limited to microDIMMsor MiniDIMMs.

To provide for persistent storage of information such as data,applications, operating systems and so forth, a storage 558 may alsocouple to the processor 552 via the interconnect 556. In an example, thestorage 558 may be implemented via a solid state disk drive (SSDD).Other devices that may be used for the storage 558 include flash memorycards, such as SD cards, microSD cards, xD picture cards, and the like,and USB flash drives. In low power implementations, the storage 558 maybe on-die memory or registers associated with the processor 552.However, in some examples, the storage 558 may be implemented using amicro hard disk drive (HDD). Further, any number of new technologies maybe used for the storage 558 in addition to, or instead of, thetechnologies described, such resistance change memories, phase changememories, holographic memories, or chemical memories, among others.

The components may communicate over the interconnect 556. Theinterconnect 556 may include any number of technologies, includingindustry standard architecture (ISA), extended ISA (EISA), peripheralcomponent interconnect (PCI), peripheral component interconnect extended(PCIx), PCI express (PCIe), or any number of other technologies. Theinterconnect 556 may be a proprietary bus, for example, used in a SoCbased system. Other bus systems may be included, such as an I2Cinterface, an SPI interface, point to point interfaces, and a power bus,among others.

The interconnect 556 may couple the processor 552 to a mesh transceiver562, for communications with other mesh devices 564. The meshtransceiver 562 may use any number of frequencies and protocols, such as2.4 Gigahertz (GHz) transmissions under the IEEE 802.15.4 standard,using the Bluetooth® low energy (BLE) standard, as defined by theBluetooth® Special Interest Group, or the ZigBee© standard, amongothers. Any number of radios, configured for a particular wirelesscommunication protocol, may be used for the connections to the meshdevices 564. For example, a WLAN unit may be used to implement Wi-Fi™communications in accordance with the Institute of Electrical andElectronics Engineers (IEEE) 802.11 standard. In addition, wireless widearea communications, e.g., according to a cellular or other wirelesswide area protocol, may occur via a WWAN unit.

The mesh transceiver 562 may communicate using multiple standards orradios for communications at different range. For example, the IoTdevice 550 may communicate with close devices, e.g., within about 10meters, using a local transceiver based on BLE, or another low powerradio, to save power. More distant mesh devices 564, e.g., within about50 meters, may be reached over ZigBee or other intermediate powerradios. Both communications techniques may take place over a singleradio at different power levels, or may take place over separatetransceivers, for example, a local transceiver using BLE and a separatemesh transceiver using ZigBee.

A wireless network transceiver 566 may be included to communicate withdevices or services in the cloud 500 via local or wide area networkprotocols. The wireless network transceiver 566 may be a LPWAtransceiver that follows the IEEE 802.15.4, or IEEE 802.15.4g standards,among others. The IoT device 550 may communicate over a wide area usingLoRaWAN™ (Long Range Wide Area Network) developed by Semtech and theLoRa Alliance. The techniques described herein are not limited to thesetechnologies, but may be used with any number of other cloudtransceivers that implement long range, low bandwidth communications,such as Sigfox, and other technologies. Further, other communicationstechniques, such as time-slotted channel hopping, described in the IEEE802.15.4e specification may be used.

Any number of other radio communications and protocols may be used inaddition to the systems mentioned for the mesh transceiver 562 andwireless network transceiver 566, as described herein. For example, theradio transceivers 562 and 566 may include an LTE or other cellulartransceiver that uses spread spectrum (SPA/SAS) communications forimplementing high speed communications. Further, any number of otherprotocols may be used, such as Wi-Fi® networks for medium speedcommunications and provision of network communications.

The radio transceivers 562 and 566 may include radios that arecompatible with any number of 3GPP (Third Generation PartnershipProject) specifications, notably Long Term Evolution (LTE), Long TermEvolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-APro). It can be noted that radios compatible with any number of otherfixed, mobile, or satellite communication technologies and standards maybe selected. These may include, for example, any Cellular Wide Arearadio communication technology, which may include e.g. a 5th Generation(5G) communication systems, a Global System for Mobile Communications(GSM) radio communication technology, a General Packet Radio Service(GPRS) radio communication technology, or an Enhanced Data Rates for GSMEvolution (EDGE) radio communication technology, a UMTS (UniversalMobile Telecommunications System) communication technology, In additionto the standards listed above, any number of satellite uplinktechnologies may be used for the wireless network transceiver 566,including, for example, radios compliant with standards issued by theITU (International Telecommunication Union), or the ETSI (EuropeanTelecommunications Standards Institute), among others. The examplesprovided herein are thus understood as being applicable to various othercommunication technologies, both existing and not yet formulated.

A network interface controller (NIC) 568 may be included to provide awired communication to the cloud 500 or to other devices, such as themesh devices 564. The wired communication may provide an Ethernetconnection, or may be based on other types of networks, such asController Area Network (CAN), Local Interconnect Network (LIN),DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among manyothers. An additional NIC 568 may be included to allow connect to asecond network, for example, a NIC 568 providing communications to thecloud over Ethernet, and a second NIC 568 providing communications toother devices over another type of network.

The interconnect 556 may couple the processor 552 to an externalinterface 570 that is used to connect external devices or subsystems.The external devices may include sensors 572, such as accelerometers,level sensors, flow sensors, optical light sensors, camera sensors,temperature sensors, a global positioning system (GPS) sensors, pressuresensors, barometric pressure sensors, and the like. The externalinterface 570 further may be used to connect the IoT device 550 toactuators 574, such as power switches, valve actuators, an audible soundgenerator, a visual warning device, and the like.

In some optional examples, various input/output (I/O) devices may bepresent within, or connected to, the IoT device 550. For example, adisplay or other output device 584 may be included to show information,such as sensor readings or actuator position. An input device 586, suchas a touch screen or keypad may be included to accept input. An outputdevice 584 may include any number of forms of audio or visual display,including simple visual outputs such as binary status indicators (e.g.,LEDs) and multi-character visual outputs, or more complex outputs suchas display screens (e.g., LCD screens), with the output of characters,graphics, multimedia objects, and the like being generated or producedfrom the operation of the IoT device 550.

A battery 576 may power the IoT device 550, although in examples inwhich the IoT device 550 is mounted in a fixed location, it may have apower supply coupled to an electrical grid. The battery 576 may be alithium ion battery, or a metal-air battery, such as a zinc-air battery,an aluminum-air battery, a lithium-air battery, and the like.

A battery monitor/charger 578 may be included in the IoT device 550 totrack the state of charge (SoCh) of the battery 576. The batterymonitor/charger 578 may be used to monitor other parameters of thebattery 576 to provide failure predictions, such as the state of health(SoH) and the state of function (SoF) of the battery 576. The batterymonitor/charger 578 may include a battery monitoring integrated circuit,such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488Afrom ON Semiconductor of Phoenix Ariz., or an IC from the UCD90xxxfamily from Texas Instruments of Dallas, Tex. The batterymonitor/charger 578 may communicate the information on the battery 576to the processor 552 over the interconnect 556. The batterymonitor/charger 578 may also include an analog-to-digital (ADC)convertor that allows the processor 552 to directly monitor the voltageof the battery 576 or the current flow from the battery 576. The batteryparameters may be used to determine actions that the IoT device 550 mayperform, such as transmission frequency, mesh network operation, sensingfrequency, and the like.

A power block 580, or other power supply coupled to a grid, may becoupled with the battery monitor/charger 578 to charge the battery 576.In some examples, the power block 580 may be replaced with a wirelesspower receiver to obtain the power wirelessly, for example, through aloop antenna in the IoT device 550. A wireless battery charging circuit,such as an LTC4020 chip from Linear Technologies of Milpitas, Calif.,among others, may be included in the battery monitor/charger 578. Thespecific charging circuits chosen depend on the size of the battery 576,and thus, the current required. The charging may be performed using theAirfuel standard promulgated by the Airfuel Alliance, the Qi wirelesscharging standard promulgated by the Wireless Power Consortium, or theRezence charging standard, promulgated by the Alliance for WirelessPower, among others.

The storage 558 may include instructions 582 in the form of software,firmware, or hardware commands to implement the techniques describedherein. Although such instructions 582 are shown as code blocks includedin the memory 554 and the storage 558, it may be understood that any ofthe code blocks may be replaced with hardwired circuits, for example,built into an application specific integrated circuit (ASIC).

In an example, the instructions 582 provided via the memory 554, thestorage 558, or the processor 552 may be embodied as a non-transitory,machine readable medium 560 including code to direct the processor 552to perform electronic operations in the IoT device 550. The processor552 may access the non-transitory, machine readable medium 560 over theinterconnect 556. For instance, the non-transitory, machine readablemedium 560 may include storage units such as optical disks, flashdrives, or any number of other hardware devices. The non-transitory,machine readable medium 560 may include instructions to direct theprocessor 552 to perform a specific sequence or flow of actions, forexample, as described with respect to the flowchart(s) and diagram(s) ofoperations and functionality described throughout this disclosure.

Example Computing Architectures

FIGS. 6 and 7 illustrate example computer processor architectures thatcan be used in accordance with embodiments disclosed herein. Forexample, in various embodiments, the computer architectures of FIGS. 6and 7 may be used to implement the visual fog functionality describedthroughout this disclosure. Other embodiments may use other processorand system designs and configurations known in the art, for example, forlaptops, desktops, handheld PCs, personal digital assistants,engineering workstations, servers, network devices, network hubs,switches, embedded processors, digital signal processors (DSPs),graphics devices, video game devices, set-top boxes, micro controllers,cell phones, portable media players, hand held devices, and variousother electronic devices, are also suitable. In general, a huge varietyof systems or electronic devices capable of incorporating a processorand/or other execution logic as disclosed herein are generally suitable.

FIG. 6 illustrates a block diagram for an example embodiment of aprocessor 600. Processor 600 is an example of a type of hardware devicethat can be used in connection with the embodiments described throughoutthis disclosure. Processor 600 may be any type of processor, such as amicroprocessor, an embedded processor, a digital signal processor (DSP),a network processor, a multi-core processor, a single core processor, orother device to execute code. Although only one processor 600 isillustrated in FIG. 6, a processing element may alternatively includemore than one of processor 600 illustrated in FIG. 6. Processor 600 maybe a single-threaded core or, for at least one embodiment, the processor600 may be multithreaded in that it may include more than one hardwarethread context (or “logical processor”) per core.

FIG. 6 also illustrates a memory 602 coupled to processor 600 inaccordance with an embodiment. Memory 602 may be any of a wide varietyof memories (including various layers of memory hierarchy) as are knownor otherwise available to those of skill in the art. Such memoryelements can include, but are not limited to, random access memory(RAM), read only memory (ROM), logic blocks of a field programmable gatearray (FPGA), erasable programmable read only memory (EPROM), andelectrically erasable programmable ROM (EEPROM).

Processor 600 can execute any type of instructions associated withalgorithms, processes, or operations detailed herein. Generally,processor 600 can transform an element or an article (e.g., data) fromone state or thing to another state or thing.

Code 604, which may be one or more instructions to be executed byprocessor 600, may be stored in memory 602, or may be stored insoftware, hardware, firmware, or any suitable combination thereof, or inany other internal or external component, device, element, or objectwhere appropriate and based on particular needs. In one example,processor 600 can follow a program sequence of instructions indicated bycode 604. Each instruction enters a front-end logic 606 and is processedby one or more decoders 608. The decoder may generate, as its output, amicro operation such as a fixed width micro operation in a predefinedformat, or may generate other instructions, microinstructions, orcontrol signals that reflect the original code instruction. Front-endlogic 606 may also include register renaming logic and scheduling logic,which generally allocate resources and queue the operation correspondingto the instruction for execution.

Processor 600 can also include execution logic 614 having a set ofexecution units 616 a, 616 b, 616 n, etc. Some embodiments may include anumber of execution units dedicated to specific functions or sets offunctions. Other embodiments may include only one execution unit or oneexecution unit that can perform a particular function. Execution logic614 performs the operations specified by code instructions.

After completion of execution of the operations specified by the codeinstructions, back-end logic 618 can retire the instructions of code604. In one embodiment, processor 600 allows out of order execution butrequires in order retirement of instructions. Retirement logic 620 maytake a variety of known forms (e.g., re-order buffers or the like). Inthis manner, processor 600 is transformed during execution of code 604,at least in terms of the output generated by the decoder, hardwareregisters and tables utilized by register renaming logic 610, and anyregisters (not shown) modified by execution logic 614.

Although not shown in FIG. 6, a processing element may include otherelements on a chip with processor 600. For example, a processing elementmay include memory control logic along with processor 600. Theprocessing element may include I/O control logic and/or may include I/Ocontrol logic integrated with memory control logic. The processingelement may also include one or more caches. In some embodiments,non-volatile memory (such as flash memory or fuses) may also be includedon the chip with processor 600.

FIG. 7 illustrates a block diagram for an example embodiment of amultiprocessor 700. As shown in FIG. 7, multiprocessor system 700 is apoint-to-point interconnect system, and includes a first processor 770and a second processor 780 coupled via a point-to-point interconnect750. In some embodiments, each of processors 770 and 780 may be someversion of processor 600 of FIG. 6.

Processors 770 and 780 are shown including integrated memory controller(IMC) units 772 and 782, respectively. Processor 770 also includes aspart of its bus controller units point-to-point (P-P) interfaces 776 and778; similarly, second processor 780 includes P-P interfaces 786 and788. Processors 770, 780 may exchange information via a point-to-point(P-P) interface 750 using P-P interface circuits 778, 788. As shown inFIG. 7, IMCs 772 and 782 couple the processors to respective memories,namely a memory 732 and a memory 734, which may be portions of mainmemory locally attached to the respective processors.

Processors 770, 780 may each exchange information with a chipset 790 viaindividual P-P interfaces 752, 754 using point to point interfacecircuits 776, 794, 786, 798. Chipset 790 may optionally exchangeinformation with the coprocessor 738 via a high-performance interface739. In one embodiment, the coprocessor 738 is a special-purposeprocessor, such as, for example, a high-throughput MIC processor, anetwork or communication processor, compression engine, graphicsprocessor, GPGPU, embedded processor, matrix processor, or the like.

A shared cache (not shown) may be included in either processor oroutside of both processors, yet connected with the processors via P-Pinterconnect, such that either or both processors' local cacheinformation may be stored in the shared cache if a processor is placedinto a low power mode.

Chipset 790 may be coupled to a first bus 716 via an interface 796. Inone embodiment, first bus 716 may be a Peripheral Component Interconnect(PCI) bus, or a bus such as a PCI Express bus or another thirdgeneration I/O interconnect bus, although the scope of this disclosureis not so limited.

As shown in FIG. 7, various I/O devices 714 may be coupled to first bus716, along with a bus bridge 718 which couples first bus 716 to a secondbus 720. In one embodiment, one or more additional processor(s) 715,such as coprocessors, high-throughput MIC processors, GPGPU's,accelerators (such as, e.g., graphics accelerators or digital signalprocessing (DSP) units), matrix processors, field programmable gatearrays, or any other processor, are coupled to first bus 716. In oneembodiment, second bus 720 may be a low pin count (LPC) bus. Variousdevices may be coupled to a second bus 720 including, for example, akeyboard and/or mouse 722, communication devices 727 and a storage unit728 such as a disk drive or other mass storage device which may includeinstructions/code and data 730, in one embodiment. Further, an audio I/O724 may be coupled to the second bus 720. Note that other architecturesare possible. For example, instead of the point-to-point architecture ofFIG. 7, a system may implement a multi-drop bus or other sucharchitecture.

All or part of any component of FIG. 7 may be implemented as a separateor stand-alone component or chip, or may be integrated with othercomponents or chips, such as a system-on-a-chip (SoC) that integratesvarious computer components into a single chip.

Embodiments of the mechanisms disclosed herein may be implemented inhardware, software, firmware, or a combination of such implementationapproaches. Certain embodiments may be implemented as computer programsor program code executing on programmable systems comprising at leastone processor, a storage system (including volatile and non-volatilememory and/or storage elements), at least one input device, and at leastone output device.

Program code, such as code 730 illustrated in FIG. 7, may be applied toinput instructions to perform the functions described herein andgenerate output information. The output information may be applied toone or more output devices, in known fashion. For purposes of thisapplication, a processing system includes any system that has aprocessor, such as, for example; a digital signal processor (DSP), amicrocontroller, an application specific integrated circuit (ASIC), or amicroprocessor.

The program code may be implemented in a high level procedural or objectoriented programming language to communicate with a processing system.The program code may also be implemented in assembly or machinelanguage, if desired. In fact, the mechanisms described herein are notlimited in scope to any particular programming language. In any case,the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented byrepresentative instructions stored on a machine-readable medium whichrepresents various logic within the processor, which when read by amachine causes the machine to fabricate logic to perform the techniquesdescribed herein. Such representations, known as “IP cores” may bestored on a tangible, machine readable medium and supplied to variouscustomers or manufacturing facilities to load into the fabricationmachines that actually make the logic or processor.

Such machine-readable storage media may include, without limitation,non-transitory, tangible arrangements of articles manufactured or formedby a machine or device, including storage media such as hard disks, anyother type of disk including floppy disks, optical disks, compact diskread-only memories (CD-ROMs), compact disk rewritable's (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash memories, electricallyerasable programmable read-only memories (EEPROMs), phase change memory(PCM), magnetic or optical cards, or any other type of media suitablefor storing electronic instructions.

Accordingly, embodiments of this disclosure also include non-transitory,tangible machine-readable media containing instructions or containingdesign data, such as Hardware Description Language (HDL), which definesstructures, circuits, apparatuses, processors and/or system featuresdescribed herein. Such embodiments may also be referred to as programproducts.

Visual Fog Architecture

FIG. 8 illustrates an example embodiment of an architecture 800 forvisual fog nodes. In some embodiments, for example, fog nodearchitecture 800 may be used to implement the functionality of fog nodes810 in a visual fog network or system (e.g., visual fog system 100 ofFIG. 1). A fog node 810, for example, can include any node or componentthat ranges from the edge of a network to the cloud, inclusively.

In the illustrated embodiment, fog node 810 includes various applicationprogramming interfaces (APIs) that provide fundamental capabilities forfog node 810, such as auxiliary API 820, primitive vision API 830, andstorage API 840. In some embodiments, for example, these APIs may beused or implemented by lower-level algorithm developers.

Auxiliary API 820 provides various fundamental functionality for fognode 810, such as security 822 a, communication 822 b, compression 822 c(e.g., codecs), and so forth.

Primitive vision API 830 provides fundamental vision processingcapabilities for fog node 810. For example, primitive vision API 830provides access to a plurality of vision kernels 832 that can be used toperform primitive vision operations (e.g., person or object detection,facial recognition). Primitive vision API 830 may also provide access tovarious machine learning and/or neural network frameworks (e.g., Caffe,OpenCV, TensorFlow).

Storage API 840 provides storage capabilities for fog node 810. In someembodiments, for example, storage API 840 may include a variety ofdatabases 842 for storing different types of visual data, such as graphdatabases, relational databases, array-based databases (e.g., TileDB),and so forth. In some embodiments, for example, the particular databaseused to store certain visual data may depend on the type of data, suchas raw visual data or pixels, compressed visual data, visual metadata,and so forth.

Moreover, fog node 810 further includes a vision application API 850that provides higher-level vision functionality, which may be used orimplemented by developers of vision applications. For example, visionapplication API 850 may include a privacy policy 852 that defines therequisite privacy treatment for all data and devices associated with avisual fog network. Vision application API 850 may also include a visionkernel management service 854 that provides access to a variety ofprimitive vision operations or vision kernels. In some embodiments, forexample, vision kernel management service 854 may retrieve visionkernels from a vision kernel repository. For example, if a particularvision application employs person detection functionality, vision kernelmanagement service 854 may retrieve the appropriate vision kernel forperforming person detection using the available hardware of theparticular fog node 810.

Fog node 810 further includes a vision analytics API 860 and query API870, which may be used by end-users or operators to perform visualanalytics and visual queries. For example, vision analytics API 860 mayperform inline (e.g. real-time) and/or offline processing of visualdata, application launching, scheduling, resource monitoring, and soforth. Vision analytics API 860 may also include a vision applicationmanagement service 862 that provides access to a variety of visionapplications (e.g., people searching/tracking, objectdetection/tracking, and so forth). In some embodiments, for example,vision application management service 862 may retrieve visionapplications from a vision application repository. In this manner, if anend-user wants to perform a people search, vision application managementservice 862 may retrieve an appropriate vision application for peoplesearching. In some embodiments, for example, a people search visionapplication may use vision kernels that perform person detectionfollowed by facial recognition. The end-user, however, can utilize thepeople search vision application without any knowledge of the underlyingvision kernels or vision operations used to implement the application.

Moreover, query API 870 provides an interface that enables end-users tosubmit visual search requests or queries. In some embodiments, forexample, query API 870 may support flexible visual queries in a varietyof syntaxes, such as natural language, functional syntax (e.g., usinglogical operators), relational syntax, and so forth. In someembodiments, query API 870 may further include a query primitiverepository 874 that contains the primitive operations that are supportedfor visual queries. Moreover, query API 870 may include a query compiler872 for compiling the visual queries into visual processing dataflowsthat can be executed by visual fog nodes.

FIG. 9-12 illustrate example embodiments of visual fog architectures.

For example, FIG. 9 illustrates an example visual fog architecture 900that includes cameras 902, sensors 904, local analytics framework 906,inline analytics framework 908, offline analytics framework 910, storage912, and presentation/interpretation framework 914. In the illustratedembodiment, for example, cameras 902 and/or sensors 904 may generatevisual data, such as images and/or video. The visual data may then beprovided to local analytics framework 906, which may be used to performpreliminary processing and analytics at the network edge (e.g., near thecameras 902 or sensors 904 that captured the visual data). The partiallyprocessed visual data may then be provided to inline analytics framework908 for further processing in real-time. In various embodiments, forexample, inline analytics may be performed by and/or distributed acrossany combination of fog devices or resources (e.g., mobile devices, IoTdevices, gateways, and/or the cloud). The resulting visual data and/ormetadata from inline analytics framework 908 may then be stored in datastorage 912. Moreover, a visual search query may be subsequentlyreceived by presentation/interpretation framework 914 (e.g., from anend-user). Accordingly, presentation/interpretation framework 914 mayinteract with data storage 912 and/or inline analytics framework 908 todetermine whether a response to the query can be formulated based on thevisual data and/or metadata that has already been processed orgenerated. If further processing needs to be performed to respond to thequery, however, presentation/interpretation framework 914 may interactwith offline analytics framework 910 to perform further offlineprocessing of the visual data. In various embodiments, for example,offline analytics may be performed by and/or distributed across anycombination of fog devices or resources (e.g., mobile devices, IoTdevices, gateways, and/or the cloud). Accordingly, based on theinformation obtained either from data storage 912, inline analyticsframework 908, and/or offline analytics framework 910,presentation/interpretation framework 914 may then respond to the visualquery.

FIG. 10 illustrates an example visual processing pipeline 1000associated with a visual fog architecture. In the illustrated example,visual data 1002 may first be captured by cameras and/or visual sensors,and the visual data 1002 may then be processed to perform certain visualfunctions 1004 (e.g., face detection) and/or other analytics, resultingin a set of visual metadata 1012 that may be stored in data storage1010. Moreover, an end-user may subsequently submit an ad hoc searchquery 1006 associated with the visual data 1002, and a querycompiler/interpreter 1008 may then compile the query into a visualprocessing dataflow that can be executed (e.g., using available fognodes or resources) in order to respond to the query. In some cases, forexample, it may be possible to formulate a query result 1016 based onthe processing that has already been completed. For example, in somecases, the query result 1016 may be formulated by applying appropriatelogic operations 1014 on the existing visual metadata 1012 that hasalready been generated. In other cases, however, further visualprocessing and/or functions 1004 may need to be performed on the visualdata 1002 in order to formulate the query result 1016. In either case,the compiler/interpreter 1008 may generate a requisite vision processingdataflow for responding to the query, and the resulting visionprocessing dataflow may then be executed in order to formulate the queryresult 1016.

FIG. 11 illustrates another example visual fog architecture 1100. In theillustrated embodiment, visual data captured by cameras 1140 b isprovided to a distributed runtime environment 1120, which performsinitial pre-processing on the visual data in real-time (e.g., when thevisual data is first captured rather than in response to a query). Theresulting visual data or metadata generated by the distributed runtimeenvironment 1120 is then stored in data storage 1130.

Separately, visual search queries containing user-defined visionfunctions (UVFs) 1104 a-c are received from end-users 1102 of visual fog1100. A UVF 1104 received from an end-user 1102 is first processed by acompiler 1110 in order to generate a vision dataflow graph for executingthe UVF. Accordingly, the vision dataflow graph is then executed by thedistributed runtime environment 1120 in order to generate a result forthe UVF 1104. In some embodiments, for example, the distributed runtimeenvironment 1120 may determine the result using existing visual metadatathat has already been generated (e.g., from the initial or real-timeprocessing of the original visual data), and/or by performing furtheranalysis on the visual data (e.g., by executing a particular visionapplication 1150). The result obtained from execution of the UVF 1104may then be provided back to the requesting end-user 1102.

Further, in various embodiments, the distributed runtime environment1120 may perform the described visual data processing (e.g., initialpre-processing and/or UVF processing) by scheduling or distributingvision workloads across the available fog devices or resources 1140(e.g., cloud servers 1140 a, cameras 1140 b, mobile devices, IoTdevices, gateways, and/or other fog/edge devices).

FIGS. 12A-B illustrate another example visual fog architecture 1200. Inthe illustrated embodiment, visual fog architecture 1200 includes anetwork of fog devices 1216, including cameras or visual sensors 1216 a,gateways 1216 b, and cloud servers 1216 c. The cameras or visual sensors1216 a, for example, are used to capture visual data 1217. Moreover, acomputer vision expert 1202 can develop an imperative vision program1203 that leverages the captured visual data 1217. The vision program1203, for example, may be implemented using programming andcomposability frameworks 1208 and 1210 to define vision processingdataflows 1209 and generate vision processing workloads 1211.

In the illustrated embodiment, for example, the vision program 1203leverages a distributed runtime environment 1214 to process visual data1217 captured in visual fog 1200. The distributed runtime environment1214, for example, can perform visual data processing using thecollection of available fog devices 1216 in visual fog 1200.

In some embodiments, for example, the distributed runtime environment1214 may be used to perform initial pre-processing on captured visualdata 1217 in real-time (e.g., when the visual data is first capturedrather than in response to a query). The resulting visual data ormetadata 1217 generated by the distributed runtime environment 1214 maythen be stored in a database or data storage 1218.

Moreover, a layperson or end-user 1204 may subsequently submit adeclarative query 1205 associated with visual data 1217 captured byvisual fog 1200. The declarative query 1205 is processed by a visualquestion answering (VQA) system 1206, which uses a compiler orinterpreter to generate a dataflow 1209 for responding to the query. Insome cases, for example, it may be possible to respond to query 1205using existing visual metadata 1217 that has already been generated(e.g., during the initial or real-time processing of the original visualdata 1217 and/or during the processing associated with prior queries1205). In other cases, however, further processing may need to beperformed on the visual data 1217 in order to respond to the query 1205.In either case, an appropriate dataflow 1209 for responding to the query1205 may be generated, and the resulting dataflow 1209 may be furtherpartitioned into one or more underlying vision processing workloads1211. Moreover, based on the resource availability 1215 of fog devices1216 in the distributed runtime environment 1214, a schedule 1213 fordistributing the workloads 1211 across the available fog devices 1216may be generated. Accordingly, the respective workloads 1211 may then bedistributed across the fog devices 1216 based on the generated schedule1213, and each fog device 1216 may execute its respective workload(s)1211. In this manner, the dataflow 1209 for responding to the query 1205is executed by the various fog devices 1216 using a distributedapproach. A response to the query 1205 may then be provided to theend-user 1204, and the resulting visual metadata 1217 may be stored indatabase 1218 for responding to subsequent queries.

Visual Question Answering (VQA)

FIG. 13-14 illustrate example embodiments associated with a visualquestion answering (VQA) framework. In some embodiments, for example, avisual fog architecture may implement a VQA framework to provide aflexible and efficient interface for end-users to submit ad hoc visualsearch queries. In visual processing systems, for example, the abilityto submit a query to search large data sets in an efficient manner(e.g., millions of images) and identify a subset of relevant images orrelated information is important. Existing visual processing solutionsare implemented using rigid or inflexible approaches, however, and areunable to search visual data efficiently. Accordingly, the visualquestion answering (VQA) framework of FIGS. 13 and 14 can be used toalleviate the deficiencies of existing solutions.

In some embodiments, for example, a VQA framework may support flexibleor ad hoc visual search queries using a variety of syntaxes, such asnatural language, functional syntax (e.g., using logical operators),relational syntax, and so forth. Accordingly, when a visual search queryis received from a user, the query may be compiled into a visualprocessing dataflow that can be distributed across and executed by thevarious fog nodes in a visual fog architecture. In this manner,end-users can perform complex searches on large sets of visual datawithout any knowledge of the underlying architecture or processingrequired to execute the searches.

Moreover, in some embodiments, users or developers may be capable ofdefining custom vision functions that can be used in visual searchqueries, referred to as user-defined vision functions (UVFs). As anexample, a UVF could be defined for visually equivalency, or performing“equal” operations on visual data. Many ad hoc visual queries, forexample, require information related to the same object or person to beidentified or grouped together. Identifying the same object or personacross different images or video streams, however, can be challenging.In some embodiments, for example, this task may require featureextraction to be performed across multiple cameras. The respectivefeatures extracted from each camera often differ, however, and not allcameras have the same field of view, and thus certain features may besuccessfully extracted from some cameras but not others. Accordingly, insome embodiments, a user may implement a UVF to define how visualequivalency or “equal” operations are to be performed on visual data. Insome embodiments, for example, a UVF for visual equivalency may defineobjects as “equal” if their feature vectors are “close enough” to eachother, meaning the feature vectors must be sufficiently similar but donot have to be an exact match. Further, if feature vectors fromdifferent cameras are missing certain features, only the partialfeatures will be compared and the “close enough” definition will bescaled accordingly.

FIG. 13 illustrates an example embodiment of a visual question answering(VQA) pipeline 1300. In the illustrated example, a visual query 1302 isfirst received from an end-user, and a dataflow compiler 1304 is thenused to compile the visual query 1302 into a visual processing pipelineor dataflow 1308. In some embodiments, for example, the dataflowcompiler 1304 may use a library of vision kernel modules 1306 (e.g.,face recognition, pose recognition, object recognition, and so forth) togenerate the resulting visual processing dataflow 1308.

In some cases, for example, the visual processing dataflow 1308 mayleverage existing visual metadata that has already been generated andstored on data storage 1314. For example, an inline analytics framework1310 may be used to perform initial visual data processing in real-time(e.g., when visual data is first captured rather than in response to aquery), and an offline analytics framework 1312 may be used to performfurther visual data processing required for responding to searchqueries. Moreover, both the inline and offline analytics frameworks1310, 1312 may store their resulting visual metadata on data storage1314 for use in responding to subsequent visual search queries.Accordingly, in some cases, the visual processing dataflow 1308 for aparticular query 1302 may leverage existing visual metadata that hasalready been generated and stored on data storage 1314. In other cases,however, further processing may be required to respond to the query1302, and thus the visual processing dataflow 1308 may leverage theoffline analytics framework 1312 to perform additional processing. Ineither case, the visual processing pipeline or dataflow 1308 generatedby compiler 1304 is executed by the runtime environment in order togenerate a response to the visual query 1302.

FIG. 14 illustrates an example embodiment of a visual question answering(VQA) compiler 1400. In some embodiments, for example, compiler 1400 maybe used to compile VQA queries and/or user-defined vision functions(UVFs) 1402 into visual dataflow graphs 1417 that can be distributedacross and executed by the various fog nodes in a visual fogarchitecture.

In the illustrated embodiment, for example, UVFs 1402 are provided tothe compiler 1400 via a declarative API 1412. The compiler 1400 may thengenerate a graph of high-level vision operations 1415 that are requiredto execute the UVFs 1402, which may in turn be used to generate a visiondataflow graph 1417. In some embodiments, for example, the visiondataflow graph 1417 may be a directed acyclic graph (DAG) thatrepresents the visual processing pipeline required to execute theparticular UVFs 1402. Moreover, the compiler 1400 may use dataflowde-duplication to optimize the vision dataflow graph 1417, for example,by merging redundant portions of the dataflows of multiple UVFs 1402 toeliminate the redundancies.

In some embodiments, for example, compiler 1400 may generate the visiondataflow graph 1417 using information from the underlying vision modules1418 (e.g., hardware-specific information required for schedulingworkloads on heterogeneous hardware). The compiler 1400 may alsogenerate a number of database API calls to obtain visual data and/ormetadata required to execute the UVFs 1402. In various embodiments,these database API calls may either be part of, or separate from, thevision dataflow graph 1417. Moreover, in some embodiments, the compiler1400 may generate different results depending on the available visualmetadata.

In this manner, the resulting vision dataflow graph 1417 generated bycompiler 1400 can subsequently be executed by the runtime environment inorder to generate the results for responding to UVFs 1402.

Runtime

The visual fog paradigm envisions tens of thousands (or more)heterogeneous, camera-enabled edge devices distributed across theInternet and/or other large-scale networks, providing live sensing for amyriad of different visual processing applications, given taskparallelism and data parallelism. The scale, computational demands, andbandwidth needed for visual computing pipelines necessitates intelligentoffloading to distributed computing infrastructure, including the cloud,Internet gateway devices, and the edge devices themselves.

In some embodiments, for example, visual processing may be scheduled ordistributed across available fog devices based on various criteria,including device connectivity, device resource capabilities, deviceresource availability, workload type, privacy constraints, and so forth.Further, machine learning can be leveraged to optimize schedulingdecisions.

Workload deployment and/or migration can be implemented using ahot-pluggable runtime environment with universal plugin APIs. Forexample, conventional workload deployment/migration can be expensive, asit may require sending the runtime environment and toolchains to theassigned nodes. With hot-pluggable runtimes, however, workloads arehot-swappable (e.g., stop runtime, replace plugin, start runtime).

Moreover, a plugin or vision kernel repository can be used to facilitateworkload deployment. For example, a cloud-based or distributedrepository may be used to manage a collection of device andimplementation abstractions for each supported vision capability. Inthis manner, the repository can distribute the appropriate plugins orvision kernels to fog nodes based on their respective workloadassignments.

Incremental processing may be leveraged by a visual fog runtime tomaintain the state of any prior processing that has already beenperformed on visual data, enabling the results of the prior processingto be leveraged for subsequent visual processing and queries. Forexample, the results of any processing performed on visual data may berepresented as visual metadata, which may be stored for later use toavoid performing duplicative processing for subsequent visual queries.In this manner, when a visual query or UVF is received, the dataflowgenerated by a compiler may vary depending on the available metadatathat has already been generated and can be reused.

Metadata pre-provisioning can be used to reduce vision query latency bypre-processing visual data to complete common or frequent types ofprocessing in advance. In some embodiments, for example, a machinelearning model may be used to optimize the types of pre-processing thatis performed. For example, based on patterns of queries of the same typeor that involve similar types of processing, machine learning may beused to model the relationships of diverse queries, while also takingother modalities into account (e.g., weather, traffic). For example,metadata can be pre-provisioned by pre-scheduling certain types ofprocessing in advance based on the recent history of vision queries andUVFs. In this manner, patterns of common or similar vision workloads cantrigger pre-processing on newly captured visual data for those types ofworkloads to reduce query latency.

Similarly, stream prioritization or prefetching can be used to performlow-latency visual data loading or fetching based on historical trendsand/or workflows. For example, the vision processing history can be usedto prioritize certain data streams and/or pre-fetch data from memory fora particular application to improve query latency. Compared to metadatapre-provisioning, which involves expedited processing that is performedin advance, stream prioritization involves obtaining or moving visualdata to a location where it will likely be needed (e.g., from a camerato certain processing nodes).

Cached visual analytics can be used to optimize visual processing usingcached workflows, similar to incremental processing. For example, basedon cached information regarding particular visual streams that havealready been obtained and processed, along with the type of processingor workloads performed on those streams, subsequent vision processingdataflows may omit certain processing steps that have previously beenperformed and whose results have been cached. For example, a visualanalytics application involves a number of primitive vision operations.The volume of computation can be reduced, however, by caching visualanalytics results and reusing them for subsequent operations whenpossible. For example, when executing a visual analytics application,cached visual metadata resulting from prior processing can be searchedto avoid duplicative computation. In some embodiments, for example,cached visual analytics may be implemented as follows:

1. Each primitive vision operation is tagged or labeled using a cachetag;

2. For each instance or stream of visual data (e.g., each stored video),any corresponding visual metadata that has already been generated isstored in a metadata database or cache;

3. If there is a cache tag hit for a particular primitive visionoperation with respect to a particular instance or stream of visualdata, then the particular primitive vision operation can be omitted andinstead the existing visual metadata can be used; and

4. If there is a cache tag miss, however, the particular primitivevision operation is executed and the resulting metadata is cached in themetadata database for subsequent use.

Tensor factorization can also be used for distributed neural networkinferencing in order to address the overfitting problem. For example,representative weights of consecutive neural network layers can utilizetensor factorization to “smooth out” the model.

FIGS. 15 and 16 illustrate example embodiments of device-centricscheduling for visual fog computing. In some embodiments, for example,visual fog scheduling may depend on (1) device resource capacities, and(2) workload resource requirements. While the former remains constantand consistent, the latter can vary depending on a device's hardwarespecifications and software toolchains. For example, in someembodiments, there may be multiple implementations of a facialrecognition capability that are respectively optimized for differenttypes of hardware, such as CPUs, GPUs, FPGAs, ASICs, and so forth. Inthis manner, multiple implementations of a single vision capability canbe leveraged to create an opportunity for further optimization in visualfog computing.

Accordingly, in order to address the heterogeneity of devices withdifferent types of hardware and/or software, the illustrated embodimentsimplement device-centric scheduling using a vision capabilitiesrepository. In some embodiments, for example, the vision capabilitiesrepository may include multiple implementations of a particular visioncapability that are optimized for different hardware and/or softwareenvironments. In this manner, vision workloads can be scheduled ordistributed across fog devices based on their respective types ofresources and capabilities, along with per-resource telemetryinformation that identifies resource availability.

The basic principle is to abstract capabilities (e.g., face detection,gesture recognition) from their underlying kernels/implementations(e.g., SIFT-based implementations, deep neural network implementations).This type of abstraction provides the flexibility to deploy an arbitraryvision capability on a per-device basis. For example, usingresource-based scheduling, heterogeneous resource types of different fogdevices can be considered as a whole in order to determine the optimaltask-to-device mapping across the various fog devices, and also identifythe corresponding vision capability implementations that each deviceshould use for its assigned tasks. Moreover, resource telemetry can beused to monitor resource availability of fog devices on a per-resourcebasis (e.g., CPU, GPU, FPGA, ASIC, and so forth) to further facilitateintelligent scheduling decisions. Further, the vision capabilityrepository hosts collections of implementations of different visioncapabilities, and may also provide a request-response service thatallows a device to request an available implementation of a particularvision capability.

In this manner, device-centric scheduling can be used to improveend-to-end (E2E) performance (e.g., latency and bandwidth efficiency)and scalability for visual fog computing.

FIG. 15 illustrates an example architecture 1500 for implementingdevice-centric scheduling in a visual computing system. In theillustrated embodiment, for example, visual computing architecture 1500includes users 1502, scheduling server 1504, vision kernel repository1506, and various types of fog devices 1510. A fog device 1510, forexample, can include any device ranging from the edge of a network tothe cloud, inclusively. In the illustrated embodiment, for example, fogdevices 1510 include cameras 1510 a, gateways 1510 b, and cloud servers1510 c.

In some embodiments, users 1502 may submit search queries for visualdata captured by cameras 1510 a. Moreover, in order to respond to thosequeries efficiently, scheduling server 1504 may schedule or distributevision processing workloads across the various fog devices 1510. In someembodiments, for example, scheduling server 1504 may perform intelligentscheduling decisions based on various criteria, such as the types ofresources in the fog (e.g., the heterogeneous types of resources of thevarious fog devices 1510), resource telemetry information (e.g., theavailability of fog resources on a per-resource-type basis), and theimplementations of vision capabilities that are available in the visioncapability repository 1506.

An example embodiment of the scheduling process, for example, isdescribed below in connection with FIG. 16.

FIG. 16 illustrates a flowchart 1600 for an example embodiment ofdevice-centric scheduling in a visual computing system. In someembodiments, for example, flowchart 1600 may be implemented using visualcomputing architecture 1500 of FIG. 15.

The flowchart may begin at block 1602 by collecting the available visioncapability implementations. In some embodiments, for example, thescheduling server continuously synchronizes the collection of availableimplementations of vision capabilities from the vision capabilityrepository.

The flowchart may then proceed to block 1604 to collect the resourcetelemetry of fog devices. In some embodiments, for example, thescheduling server may collect the resource availability of all fogdevices on a per-resource-type basis. For example, the scheduling servermay collect information regarding the resource availability of CPUs,GPUs, FPGAs, ASICs, and/or any other resource type across all fogdevices.

In this manner, based on the available vision capability implementationscollected at block 1602, and the resource telemetry informationcollected at block 1604, the scheduling server can subsequently schedulevision workloads based on the optimal task-to-device mapping in thevisual fog paradigm.

For example, the flowchart may then proceed to block 1606 to determinewhether a new vision workload has been received from a user. In someembodiments, for example, a user may submit a new visual query, whichmay require a new vision workload to be scheduled or distributed acrossthe fog devices.

If it is determined at block 1606 that a new vision workload has NOTbeen received, the flowchart may then proceed back to block 1602 tocontinue synchronizing the available vision capability implementationsand collecting resource telemetry information until a new visionworkload is received.

If it is determined at block 1606 that a new vision workload has beenreceived, the flowchart may then proceed to block 1608 to re-scheduleall pending workloads. In some embodiments, for example, receiving a newvision workload for a user may trigger the scheduling server tore-schedule all pending workloads to ensure the collective workloads aredistributed across the fog devices in the most efficient manner possible(e.g., based on the optimal task-to-device mapping).

In some embodiments, for example, scheduling may be performed based onvarious criteria, such as the types of fog resources that are available,telemetry information for those resources, and the vision capabilityimplementations that are available for those fog resources.

In some embodiments, for example, a schedule that adheres to theconstraints of multiple resource types can be determined using integerlinear programming (ILP). Integer linear programming (ILP) is amathematical optimization or feasibility technique for solving oroptimizing a mathematical model represented by linear relationships. Inparticular, ILP can be used to optimize a linear objective function,subject to additional linear equality and linear inequality constraints.As an example, an ILP problem can be expressed as follows:

-   -   minimize: c^(T)x (objective term)    -   subject to: Ax≤b (inequality constraint)        -   Cx=d (equality constraint)    -   and: x∈{0, 1}^(K) (binary constraint).

Moreover, this ILP model can be used to determine an optimal schedule fthat satisfies a specified objective (e.g., total network utilization),while also adhering to other additional constraints (e.g., deviceresource constraints). In the above ILP model, for example, x presentsthe collection of possible schedules f, K is the length of x, theobjective term presents a scheduling objective to be minimized (e.g.,total network utilization), and the inequality/equality constraintspresent any additional constraints (e.g., device, resource, network,mapping, and/or privacy constraints). A device resource constraint, forexample, can be presented as an inequality constraint of the ILP model.For example, in order to take into account constraints of multipleresource types, they can be expended into multiple inequalities in theform of Ax b in the ILP model above.

Accordingly, based on the scheduling decisions, the scheduling serverassigns each fog device zero or more tasks. In some embodiments, forexample, a task may be specified in a tuple of the form t=(p, r), wherep denotes the vision capability and r denotes resource type (e.g.,p=face detection, r=Movidius processor).

The flowchart may then proceed to block 1610 to determine if an updatedworkload schedule is available. For example, after a new vision workloadis received and the pending workloads are re-scheduled, the schedulingserver may have an updated or improved workload schedule that needs tobe distributed to the fog devices. In some embodiments, however, thescheduling server may only update the workload schedule if the newlygenerated schedule is better or more efficient than the current workloadschedule.

If it is determined at block 1610 that the workload schedule has NOTbeen updated, the flowchart may then proceed back to block 1602 tocontinue synchronizing the available vision capability implementationsand collecting resource telemetry until the current workload schedule iseventually updated.

However, if it is determined at block 1610 that an updated workloadschedule is available, the flowchart may then proceed to block 1612 topush the updated schedule to all fog devices.

The flowchart may then proceed to block 1614 to receive requests fromfog devices for vision capability implementations. For example, each fogdevice may query the vision capability repository to requestimplementations of vision capabilities for the tasks assigned to theparticular fog device. In some embodiments, for example, the requestfrom a particular fog device may identify each of its assigned tasks t.

The flowchart may then proceed to block 1616 to identify the appropriatevision capability implementations for each fog device. In someembodiments, for example, the vision capability repository may be adictionary of key-value pairs in the form of (task t, implementation i),where an implementation i can be distributed in various forms (e.g., adynamic linking library in C/C++). Accordingly, based on the task(s) tspecified in the request from a particular fog device, the visioncapability repository identifies the corresponding implementation(s) ifor that fog device. In some embodiments, for example, the visioncapability repository identifies the optimal implementation of eachvision capability requested by a fog device based on the availableresources of that fog device.

The flowchart may then proceed to block 1618 to distribute theidentified vision capability implementations to each fog device. In thismanner, each fog device can then perform its assigned tasks using theappropriate vision capability implementations.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 1602 to continue scheduling vision workloads.

FIG. 17 illustrates an example embodiment of a runtime processingpipeline 1700 for a visual fog architecture. In the illustratedembodiment, for example, a raw stream of visual data 1701 (e.g., videoor images) captured by cameras or visual sensors in a visual fogarchitecture is provided as input to a stream ingress framework 1702.The stream ingress framework 1702 decodes the raw stream of visual data1701, and a decoded stream 1703 is then provided as input to adistributed pre-processing framework 1704. The distributedpre-processing framework 1704 then performs some preliminary processingusing certain fog resources at the network edge (e.g., near the camerasor sensors that captured the visual data), such as data pre-processing,filtering, and/or aggregation. The resulting filtered stream 1705 maythen be stored in data storage 1706 for subsequent use in responding tovisual search queries and/or user-defined vision functions (UVFs) 1709from end-users.

For example, end-users may subsequently submit visual search queriesand/or user-defined vision functions (UVFs) 1709 associated with thevisual data captured by the visual fog system. Accordingly, the UVFs1709 are provided to a UVF compiler 1710, which compiles the UVFs 1709into a vision dataflow graph 1711 that can be used to execute the UVFs.For example, the vision dataflow graph 1711 is provided to a distributedUVF execution framework 1712, which distributes or schedules workloadsassociated with the vision dataflow graph 1711 across the available fognodes in the visual fog architecture.

After the workloads finish executing, the distributed UVF executionframework 1712 generates an output 1713 resulting from execution of theUVFs 1709. For example, the output 1713 may include, or may be derivedfrom, a filtered stream of visual data and/or metadata 1707 generated byexecution of the UVFs 1709. Moreover, in some embodiments, the resultingstream of visual data and/or metadata 1707 may then be stored in datastorage 1706 for responding to subsequent visual search queries or UVFs.

Storage

As the volume of visual data generated in the real-world continues togrow, it is becoming increasingly common for visual data to be processedautomatically by computers rather than manually reviewed by humans. Dueto the increasing volume of visual data, however, data access has becomea bottleneck in visual data processing, as existing visual data storageapproaches suffer from various deficiencies.

To illustrate, image classification is a common visual data operationthat uses a neural network to identify the contents of an image. Forexample, in machine learning, a convolutional neural network (CNN) is atype of feed-forward artificial neural network where the input isgenerally assumed to be an image. CNNs are commonly used for imageclassification, where the goal is to determine the contents of an imagewith some level of confidence. For example, a CNN is first trained for aspecific classification task using a set of images whose object classesor features have been labeled, and the CNN can then be used to determinethe probability of whether other images contain the respective objectclasses.

Visual data (e.g., images, video) must first be loaded from a storagesystem before it can be processed by a CNN. In the past, the data accesslatency has typically been less than the CNN vision processing latency,allowing the data access to be performed during the CNN processing.However, as hardware and software optimizations continue to improve theperformance of CNN vision processing algorithms, the data access latencyof existing solutions has become the bottleneck. Moreover, existingsolutions typically store visual data in its original format rather thana format designed to aid with visual data processing, which furtherhinders performance.

Existing solutions are also unable to efficiently search visual data.For example, given a large data set (e.g., millions of images), theability to efficiently identify a subset of relevant images using aquery is important. The output of a CNN used for image classificationtypically includes a vector of values corresponding to the probabilityof various objects existing in an image. However, existing solutionstypically use this information for the task at hand and then discard it,requiring the processing to be repeated for subsequent use. For example,a CNN used to process an image with a dog and a cat may provide aprobability for both, but if the goal was to find images with dogs, theinformation about cats is typically lost or discarded, thus preventingfuture use. In this manner, a subsequent search for images that containcats would typically require the CNN to be run again on each image.

Accordingly, FIG. 18 illustrates an example embodiment of a visual datastorage architecture 1800 designed to provide efficient access to visualdata and eliminate the deficiencies of existing storage solutions usedfor visual data processing. In particular, storage architecture 1800provides efficient metadata storage for searching visual data, as wellas analysis-friendly formats for storing visual data.

In the illustrated embodiment, for example, storage architecture 1800includes a request server 1802 for receiving visual search queries froma client API 1801, a metadata database 1804, a visual compute library1806, and a persistent data storage 1810, as explained further below.

In some embodiments, for example, storage architecture 1800 may providea unified API 1801 for visual data access (e.g., for both visual dataand metadata). For example, visual data is commonly stored directly asfiles or in various types of databases (e.g., key-value, relational,and/or graph databases). Visual metadata is typically stored indatabases, for example, while images and videos are typically stored asfiles. Moreover, different types of file systems and databases provideAPI functions in various programming and/or query languages in order toenable users to access and store data. Accordingly, in some embodiments,visual storage architecture 1800 may be implemented with a unified API(e.g., JSON-based) that supports multi-modal queries for retrieving anytype of visual data from any storage source. In some embodiments, forexample, the unified API could be used to retrieve and/or combine visualmetadata and the original visual data from different storage locations.The unified API may also allow certain types of processing to beperformed on visual data before it is returned to the requesting user.Further, the unified API may allow users to explicitly recognize visualentities such as images, feature vectors, and videos, and may simplifyaccess to those visual entities based on their relationship with eachother and with other entities associated with a particular visionapplication.

Moreover, in some embodiments, a multi-tier lazy data storage approachmay be used to store visual data more efficiently (e.g., using long- orshort-term storage in different portions of the distributededge-to-cloud network). For example, multiple storage tiers may be usedto store visual data in different locations and for varying amounts oftime based on the type or importance of the visual data. In someembodiments, for example, video cameras may store all video capturedwithin the past day, gateways may store video with motion activitieswithin the past week, and the cloud may store video associated withcertain significant events within the past year.

Similarly, intelligent placement and aging of visual data across thestorage tiers may further improve the data storage efficiency (e.g.,determining where to store the visual data within the distributededge-to-cloud system, when the data should be moved from hot to warm tocold storage, and so forth). For example, visual data and metadata canbe distinguished and segregated based on data access patterns. Moreover,analysis friendly storage formats can be used to enable data to be readfaster when needed for vision processing. These various data formats maybe used to form the hot, warm, and cold tiers of data that can be mappedto various heterogeneous memory and storage technologies, based on theintended use and lifetime of the data. For example, storage tiers can beused to represent hot, cold, and optionally warm data. Hot data isaccessed frequently; warm data is accessed occasionally; and cold datais accessed rarely (if ever). Accordingly, cold data may be stored onslower hardware since low access latency for retrieval of the data isless important. In this manner, intelligent decisions can be used todetermine when and which portions of visual data should remain in thehot tiers and when it should be migrated to colder tiers, and whichstorage format should be used. For example, regions of interest mayremain in hot storage in the analysis friendly format much longer thanthe entire image/video.

Metadata database 1804 is used to store metadata in a manner thatfacilitates efficient searches of visual data. For example, whenperforming image classification using a CNN, the resulting image-objectrelationships or probabilities can be stored as metadata, and themetadata can be used for subsequent searches of the images, thuseliminating the need to repeatedly process the images for each search.For example, FIG. 19 illustrates an example of a vision processingpipeline 1900 that leverages metadata for searching visual data. In theillustrated example, a stream of incoming visual data is received from anetwork or file system at block 1902, vision processing is performed onthe visual data to derive metadata (e.g., using a CNN) at block 1904,the metadata is stored at block 1906, search queries for relevant visualdata are received at block 1908, and the search queries are thensatisfied using either the metadata obtained at block 1906 or additionalvision processing performed at block 1904.

In some embodiments, storage architecture 1800 may store visual metadataas a property graph to identify relationships between visual data, suchas images that contain the same object or person, images taken in thesame location, and so forth. For example, FIGS. 20 and 21 illustrateexamples of representing visual metadata using a property graph. In thismanner, visual metadata can be easily searched to identify theserelationships, thus enabling flexible search queries such as “find allimages taken at location Y that contain person A.”

Moreover, in some embodiments, metadata database 1804 of storagearchitecture 1800 may be implemented as a persistent memory graphdatabase (PMGD) to enable visual metadata to be searched moreefficiently. For example, using persistent memory (PM) technology, agraph database containing the visual metadata can be stored bothin-memory and persistently. In this manner, a persistent memory graphdatabase (PMGD) can be designed to leverage a memory hierarchy with datastructures and transactional semantics that work with the PM cachingarchitecture, reduce write requests (addressing PM's lower writebandwidth compared to DRAM), and reduce the number of flushes and memorycommits. This approach enables a graph database of visual metadata to besearched efficiently to identify relevant visual data.

Further, feature vector storage optimizations may be used to achievefast searching of visual metadata. For example, feature vectors can begenerated by various vision algorithms to identify regions or featuresof interest in visual data (e.g., faces, people, objects), and they aretypically represented as vectors of n-dimensional floating-point values.Finding the nearest neighbor for a given feature vector is a commonoperation that is computationally expensive, especially at the cloudscale due to billions of potential feature vectors (e.g., a featurevector for each interesting region of each image or video frame).Accordingly, in some embodiments, feature vectors may be represented andstored as visual metadata using an efficient format. For example, visualmetadata may be stored using an analysis-friendly array format thatindicates where the feature vectors reside, and an index may be built oninteresting dimensions within the metadata storage to narrow the searchspace.

Storage architecture 1800 also includes a separate data storage 1810 forstoring the visual data itself, such as images or videos. Segregatingthe metadata and visual data in this manner enables each type of data tobe mapped to the most suitable hardware in a heterogeneous system, thusproviding flexibility for the request server 1802 to identify the mostefficient way to handle a visual data request.

Moreover, storage architecture 1800 is also capable of storing visualdata on data storage 1810 using an analytic image format designed to aidin visual processing. In the illustrated embodiment, for example, visualcompute library (VCL) 1806 of storage architecture 1800 is designed tohandle processing on analytic image formats 1807 in addition totraditional formats 1808. For example, visual compute library 1806 canimplement an analytic image format 1807 using an array-based datamanagement system such as TileDB, as described further with respect toFIG. 22. The analytic image format 1807 provides fast access to imagedata and regions of interest within an image. Moreover, since theanalytic image format 1807 stores image data as an array, the analyticimage format 1807 enables visual compute library 1806 to performcomputations directly on the array of image data. Visual compute library1806 can also convert images between the analytic image format 1807 andtraditional image formats 1808 (e.g., JPEG and PNG). Similarly, videosmay be stored using a machine-friendly video format designed tofacilitate machine-based analysis. For example, videos are typicallyencoded, compressed, and stored under the assumption that they will beconsumed by humans. That assumption is often leveraged for videoencoding by eliminating information that human eyes and brains cannotprocess. Videos intended for machine-based processing, however, maybenefit from alternative storage methods designed to speed up the timerequired to retrieve full images or regions of interest within a videoor video frame, and even enhance the accuracy of machine-learning videoprocessing mechanisms.

FIG. 22 illustrates an example embodiment of an analytic image format2200 designed to aid in visual data processing. In some embodiments, forexample, storage architecture 1800 may use analytic image format 2200 tostore images in a format that facilitates visual data processing andanalysis.

Deep learning neural networks, such as CNNs, are frequently used forimage processing, including object/edge detection, segmentation, andclassification, among other examples. Images are typically read fromdisk during both training and inferencing, for example, using backgroundthreads to pre-fetch images from disk and overlap the disk fetch anddecode times with the other compute threads. However, compute cycles maystill be wasted reading the images from disk and decompressing/decodingthe images to prepare them for processing, thus reducing the overallthroughput (e.g., images/second) of an image processing system.

Moreover, traditional lossy image formats (e.g., JPEG) are designed tocompress image data by discarding high-frequency information that is notperceptible by humans. While the discarded information may bemeaningless to humans, however, it can improve the accuracy andperformance of deep learning neural networks used for image processing.

For example, images can be compressed either in a lossless or lossymanner. Lossless image compression preserves all the information in theimage, while lossy compression takes advantage of visual perception andstatistical properties to achieve better compression rates, but resultsin some data being lost. The JPEG compression algorithm is a commonlyused lossy algorithm that is often used for images on the web. The JPEGalgorithm is based on discrete cosine transforms (DCT), and discardshigh-frequency details that are not perceptible to the human eye, whichresults in much smaller image file sizes. However, in cases where exactimage reproduction is required, or when the image will be editedmultiple times, lossless compression is preferred. For example, PNG isan image file format that supports lossless compression using a bitmapimage. With PNG, images are transformed using a filter type on aper-line basis, and then compressed using the DEFLATE algorithm. Thereare numerous other image formats with similar technologies behind themthat are suitable for different applications and use cases. While atraditional lossless image format (e.g., PNG) could be used to retainall image data for image processing purposes, that comes at the cost ofa lower compression rate.

Further, images stored using traditional formats (e.g., JPEG and PNG)must be converted into an internal array format before any processingcan begin. For example, before any operations can be performed on imagesstored using traditional formats, the entire image file must be readfrom disk and decoded into an internal array format. In analytics,however, operations such as resizing and cropping are often performedbefore any sort of learning or understanding happens, thus renderingtraditional image formats inefficient for image processing andanalytics.

Accordingly, traditional image formats (e.g., JPEG and PNG) are designedfor human consumption, and performing operations on them is oftentime-consuming and inefficient. Moreover, lossy image formats (e.g.,JPEG) discard information that may be useful in machine learning, andthus are not well-suited for image processing. Moreover, while existingdatabase management systems could be used to store images, they are notdesigned for image data and thus do not store image data efficiently.

The analytic image format 2200 of FIG. 22 is designed to aid in imageprocessing and alleviate the deficiencies of existing image formats. Forexample, image format 2200 is implemented using an array-based datastorage format that is lossless and eliminates the expensive decodingprocess that is required for processing traditional image formats. Insome embodiments, for example, analytic image format 2200 could beimplemented using an array-based data storage manager such as TileDB.TileDB is a data management system designed for efficiently managinglarge volumes of scientific data represented using arrays. While TileDBis not specific to images, it is designed to provide fast access toarray-based data. Accordingly, in some embodiments, image format 2200can be implemented using TileDB to achieve the performance boost ofTileDB for image processing purposes.

In some embodiments, for example, analytic image format 2200 can beimplemented by defining how the pixel data of an image is stored andaccessed in an array-based format (e.g., using an array-based datastorage manager such as TileDB). In this manner, image format 2200enables efficiency in processing large images, which reduces the overalltime for image analytics. As visual understanding algorithms get fasterand the hardware to perform the algorithms gets better, the time toretrieve and process the images is becoming more and more significant.However, by using analytic image format 2200, storage and retrieval ofimages does not become a bottleneck in the visual processing pipeline.

For example, analytic image format 2200 allows an image to be stored asa lossless compressed array of pixel values. Accordingly, when imagedata is needed for processing, the image data does not need to bedecoded before being processed, as required for traditional imageformats. This improves the speed at which data is retrieved and madeusable, yet still provides some level of compression. While thisapproach requires images to be written to the analytic image format 2200prior to training or inference, the additional write overhead isminimal.

Moreover, because TileDB outperforms many array database managers forboth sparse and dense data access, it is an ideal choice forimplementing analytic image format 2200. In other embodiments, however,analytic image format 2200 can be implemented using any other type ofarray-based data manager or data format. The use of a fast, enhancedarray storage system such as TileDB enables image format 2200 toeliminate slow reads of images from disk, and remove the in-loopconversion of traditional image formats to arrays.

Image format 2200 is also beneficial in applications where subarrayaccesses are common, such as accessing regions of interest in an image.For example, an array data manager such as TileDB can be used to improvethe speed of common operations that are needed for image analytics, suchas resize and crop, by enabling fast subarray accesses.

FIG. 22 illustrates the process of converting an image into an analyticimage format 2200 using an array-based data manager such as TileDB. Inthe illustrated example, the original image is first received 2202 andis then divided into a plurality of tiles 2204 using an optimal tilesize, and the tiles are then compressed and written to memory on aper-tile basis 2206 using an array-based storage format.

In some embodiments, the optimal tile size for analytic operations canbe dynamically determined for each image. For example, in order todetermine the optimal tile size for a particular image, a random portionof the image may be selected and then processed using different tilesizes and compression algorithms in order to determine the ideal tilesize and compression for that image. Moreover, since image processingoperations are often postponed until the data is actually needed, thereis a period of time available to carry out the experimentation withoutimpacting performance.

An image that does not fit perfectly into tiles of the selected tilesize will have partially empty tiles that are padded with emptycharacters, as depicted in FIG. 22. In this manner, the original size ofthe image may be stored as metadata (e.g., height, width, and number ofchannels), and when the image is subsequently read from storage, themetadata can be checked to determine the actual dimensions of the imageto avoid reading the empty characters or padding.

For high-resolution images, image format 2200 improves the speed ofcommon operations such as reading and writing, as well as the speed ofoperations used in image analytics, such as cropping and resizing. Forexample, storing images using image format 2200 improves readperformance, as the images are compressed but not encoded, and thus donot need to be decoded when they are read from the file system. Inaddition, image format 2200 enables fast access to subarrays of imagepixels, making cropping a simple matter of reading a particular subarrayrather than reading the entire image and then cropping it to theappropriate size.

For example, FIG. 23 illustrates a graph 2300 comparing the performanceof analytic image format 2200 from FIG. 22 with the PNG image format,which is a traditional lossless image format. As shown by FIG. 23, theanalytic image format provides better performance than PNG for writes,reads, crops, and resizes. The largest improvement is seen in cropping,as the analytic image format allows only the pertinent information to beread from the file, rather than reading the entire image file and thencropping to the desired size. Accordingly, the performance improvementfor common data access and analytic operations demonstrates thatanalytic image format 2200 is highly beneficial for image processingpurposes.

FIG. 50 illustrates an example write processing flow 5000 fortraditional and analytic image formats. In the illustrated processingflow 5000, for example, raw pixel data 5002 can be written to disk 5010using either a traditional image format or an analytic image format. Thetop path of processing flow 5000 illustrates the flow for writingtraditional image formats (e.g., PNG), while the bottom path illustratesthe flow for writing analytic image formats.

With respect to traditional image formats, for example, raw pixel data5002 is encoded 5004, compressed 5006, and then stored 5010. Withrespect to analytic image formats, however, raw pixel data 5002 iscompressed 5008 and then stored 5010, but the encoding step is omitted.While the resulting analytic image format may result in a larger filesize on disk, the latency of data access operations (e.g., writes) andother image operations may be reduced.

Moreover, the read processing flow for traditional and analytic imageformats may be implemented as the reverse of the write processing flow5000. For example, with respect to traditional image formats, theencoded/compressed data is read from disk, decompressed, and thendecoded into the original image. With respect to analytic image formats,the compressed data is read from disk and then decompressed into theoriginal image, but the decoding step is omitted since the encoding stepwas omitted during the write processing flow 5000.

TABLE 1 illustrates an example analytic image format schema. In someembodiments, for example, the analytic image format schema of TABLE 1could be implemented using an array-based database manager (e.g.,TileDB) to store images as dense arrays.

TABLE 1 example analytic image format PARAMETER TYPE EXAMPLE VALUE cellorder fixed row major tile order fixed row major number of dimensionsfixed   2 dimension names fixed “height”, “width” number of attributesfixed   1 compression fixed LZ4 array height variable 3534 array widthvariable 5299 domain variable [0, 3533, 0, 5298] tile height variable 589 tile width variable  757

The schema of TABLE 1 specifies parameters about the array that can beused to arrange the image data. Moreover, some parameters of theanalytic image format are fixed, while others are determined on aper-image basis. For example, images have only two dimensions, a heightand a width, thus fixing the number of dimensions as well as the namesof the dimensions. The number of attributes is set to one, which meanseach cell holds the blue, green, and red (BGR) values for thecorresponding pixel. All three values are generally read together, as apixel is defined by all three values. In other embodiments, however, thecolor values may be stored separately. The intra-tile and array-leveltile ordering is fixed to be row major. Row major order means that datais written and read from left to right in rows within a tile, and tilesare written and read in the same manner. This information allows thearray database to efficiently perform subarray reads.

The dimensions and domain of the array depend on the resolution of theoriginal image and therefore are calculated dynamically on a per-imagebasis. Since images often do not have an evenly divisible number ofpixels in one or both dimensions, this occasionally results in thedimensions of an array not matching the original resolution of theimage. This is reflected in TABLE 1, where the array height is one pixellarger than the image height. To make up the difference between an imagedimension and an array domain, the image is padded with emptycharacters. An example of this can be seen in FIG. 22, where the whitespace within certain tiles corresponds to empty characters. In theactual array, the size of the array domain is increased by a singlepixel when needed. The original size of the image (height, width, andnumber of channels) is stored as metadata by default. When an image inthe analytic format is read, the metadata is read first in order todetermine the dimensions of the image, thus avoiding reading the emptycharacters.

Tile extents depend on the array dimensions and are calculated once thearray dimensions are known. All tiles have the same height and width.The optimal number of tiles may vary based on image content andresolution, and thus in some embodiments, the optimal number of tilesmay be determined on a per-image basis. For example, in order todetermine the best tile size, a portion of the image may be randomlyselected and tested using different tile sizes and compressionalgorithms to determine the best combination for that image. Since alloperations are postponed until the data is actually needed, there is aperiod of time to carry out the experimentation that does not affect theperformance. In other embodiments, however, a predefined minimum numberof tiles per dimension (e.g., 4 tiles per dimension) may be used as abasis to determine tile height and width.

The compression algorithm used to compress the analytic image data has afixed default (e.g., the LZ4 compression algorithm), but othercompression algorithms can be set manually.

FIG. 51 illustrates an example embodiment of a visual compute library(VCL) 5100 for traditional and analytic image formats. For example, VCL5100 provides an interface through which a user can interact with theanalytic image format as well as traditional image formats.

When a user creates an analytic image using VCL 5100, the analytic imageschema is automatically set using the parameters described above inTABLE 1. VCL 5100 then creates a layer of abstraction with functioncalls of TileDB 5102 (e.g., the array-database manager used in theillustrated embodiment) combined with specialized transformationoperations to provide an interface to the analytic image. VCL 5100 alsoextends the abstraction layer to OpenCV 5104, providing support for PNGand JPEG image formats. VCL 5100 uses OpenCV 5104 to perform both I/Oand transformation operations on images that are stored in either PNG orJPEG format. For images stored in the analytic format, VCL 5100 handlesthe transformation operations and uses TileDB 5102 for I/O operations.

To initially store an image in the analytic format, the raw pixel dataof an image is passed to VCL 5100 in some manner (e.g., as a path to aPNG or JPEG file stored on disk, an OpenCV matrix, a buffer of encodedpixel data, a buffer of raw pixel data, and so forth). This data isconverted to a raw pixel buffer in order to write to the analyticformat. Since the TileDB array schema for images has already been set atthis point (e.g., using the parameters of TABLE 1), the TileDB functionscan be used to write the data to disk.

Reading an image in the analytic format requires the metadata to be readfirst to determine the original image resolution. This ensures that onlyimage data is read and that empty characters are ignored. The rawanalytic-format or TileDB data is read into a buffer, keeping the datain the order in which it was written, which is referred to as “tileorder” (e.g., as illustrated in FIG. 52). This is because if the datanever needs to be returned to the user (e.g., if the user just wants tomanipulate it and write it out again), it is faster to use the tileorder buffer. In cases where the data is to be returned to the user,however, the buffer is re-ordered into image order, which results in abuffer that has each row of the image sequentially (e.g., as illustratedin FIG. 52). Image order, for example, is typically expected by otherprograms such as OpenCV 5104.

Crop, another frequently used operation in image processing, is used toretrieve a region of interest within an image for processing. Ratherthan reading the entire image and then selecting a sub-region (as isrequired for traditional image formats), the analytic or TileDB cropfunction uses the crop parameters to specify a subarray of the analyticimage data. The subarray is then the only portion of the image that isread.

Resize, another frequently used operation in image processing, is usedto resize the dimensions of an image (e.g., to either a smaller orlarger size). The TileDB resize occurs after the image has been read,but while the data is still in tile order. VCL 5100 implements a versionof resize for TileDB that uses a bilinear interpolation, following theOpenCV default. For example, in a linear interpolation, a new value iscalculated based on two points; bilinear interpolation does this in twodifferent directions and then takes a linear interpolation of theresults. These points are identified by (row, column) in the originalimage. Given the data is in tile order, it is necessary to identifywhich tile each point is part of in order to locate the value of thatpoint in the buffer. The resulting resized image buffer is in imageorder, although other approaches may be used to keep it in tile order.

Compression/Compressive Learning

The performance of large-scale visual processing systems can be improvedusing efficient compression algorithms and techniques for storing andprocessing visual data. The compression approaches of existing visualprocessing solutions, however, suffer from various deficiencies. Forexample, existing solutions require visual data to be fully decompressedbefore any processing can be performed (e.g., using deep learning neuralnetworks). Moreover, existing solutions typically compress and storeimages individually, thus failing to leverage the potential compressivebenefits of collections of similar or related images with redundantvisual data.

Accordingly, this disclosure presents various embodiments forcompressing and processing visual data more efficiently. In someembodiments, for example, neural networks can be designed to operate oncompressed visual data directly, thus eliminating the need to decompressvisual data before it can be processed. Moreover, context-awarecompression techniques can be used to compress visual data and/or visualmetadata more efficiently. For example, context-aware compression can beused to compress distinct instances of redundant visual data moreefficiently, such as a group of images taken close in time, at the samelocation, and/or of the same object. Similarly, context-awarecompression can be used to compress visual metadata more efficiently(e.g., using a context-aware lossless compression codec). In someembodiments, for example, visual metadata could be compressed bypre-training a convolutional neural network (CNN) to classify visualmetadata, replacing long strings of visual metadata with shorter symbols(e.g., pre-defined human codes), performing multi-scale de-duplicationon the visual metadata, and finally compressing the resulting visualmetadata using a compression algorithm (e.g., the LZ77 losslesscompression algorithm or another similar alternative).

FIGS. 24A-C illustrate an example embodiment of a multi-domain cascadeconvolutional neural network (CNN) 2400.

In distributed visual analytics systems, image and video is oftencompressed before transmission (e.g., from the pixel domain to acompressed domain), and subsequently decompressed after transmission(e.g., back to the pixel domain) before any processing can be performed,such as deep learning using neural networks. As an example, image andvideo captured by edge devices may be compressed and transmitted to thecloud, and then decompressed by the cloud before any further processingbegins.

This approach suffers from various disadvantages. First, extracomputation is required to fully decompress the visual data before itcan be processed, thus significantly increasing the total processingtime (e.g., by up to 100% in some cases). For example, before processingcan be performed, the visual data must be fully decompressed back to thepixel domain using hardware or software decoding. Accordingly, giventhat not all processors include built-in video decompressionaccelerators, decompression may incur an additional cost for videoanalytics.

Next, extra bandwidth is required to transmit the decompressed databetween separate processing components (e.g., between a decompressionengine and an analysis engine), thus significantly increasing bandwidthusage (e.g., by up to 20 times in some cases).

Moreover, the requirement to fully decompress visual data prior toprocessing precludes the ability to leverage a fully distributed neuralnetwork in the edge-to-cloud sense. For example, the use of distributedanalytics to process visual data exclusively in the pixel domainrequires the visual data to be analyzed at multiple scales.

Further, relying on the cloud to perform processing on visual datacaptured by edge devices often results in wasted transmission bandwidth,as many images or videos transmitted from the edge to the cloud may notcontain any objects or features of interest. In many cases, for example,it could be possible to perform object detection and classificationcloser to the network edge (e.g., near the sensors that capture thevisual data) using lower complexity analytics algorithms, potentiallysaving the transmission cost of insignificant or unimportant data.

Accordingly, FIGS. 24A-C illustrate an example embodiment of amulti-domain cascade CNN 2400 that can be used to process visual data inthe compressed and pixel domains, thus eliminating the requirement todecompress visual data before it can be processed. In this manner,multi-domain cascade CNN 2400 can be used to perform distributed visualanalytics in a visual fog system using compressed domain data as input.

In some embodiments, for example, multi-domain cascade CNN 2400 may be acascaded CNN that includes multiple decision stages. For example, in afirst or early decision stage, a subset of the compressed domain visualdata or features may be used (e.g., motion vectors) to attempt togenerate an early decision. If the visual data cannot be detected orclassified in the early stage, additional compressed domain data (e.g.,motion prediction residuals) may be provided as input to a subsequent orlate decision stage. Finally, for improved accuracy and/or in the eventthe late decision stage is unsuccessful, the visual data may be fullydecompressed and a final decision stage may be performed using thedecompressed visual data.

In the illustrated embodiment, for example, CNN 2400 includes an earlydecision stage (illustrated in FIG. 24A), a late decision stage(illustrated in FIG. 24B), and a final decision stage (illustrated inFIG. 24C). Moreover, CNN 2400 is designed to process compressed visualdata 2402 as input (e.g., video sequence data compressed with amotion-compensated predictive coding scheme such as H.264).

In some embodiments, for example, compressed visual data 2402 providedas input to CNN 2400 may first be partially decoded to separate andextract different syntax elements (e.g., motion vectors, macroblock (MB)coding modes, quantized prediction residuals), thus producing a subsetof partial compression data 2404.

As shown in FIG. 24A, in the early decision stage, the partialcompression data 2404 (e.g., motion vectors) is provided as input to afirst stage CNN 2405 a to attempt to identify an early decision 2406. Insome embodiments, the CNN processing may then terminate if an earlydecision can be made. For example, in some embodiments, the earlydecision stage may be performed by a fog or edge node near the sensorthat captured the visual data. Accordingly, if an early decision can bemade, it may be unnecessary to transmit additional visual data toanother node (e.g., in the cloud) for a subsequent processing stage,thus saving bandwidth and/or resources (e.g., energy) that wouldotherwise be required for the later stage. For example, assuming thegoal is to detect moving pedestrians using traffic cameras, if there isno motion detected, there likely are no moving objects. Accordingly, anearly decision can be made, and any further transmission or processingof the visual data can be aborted. In other embodiments, however, thesubsequent CNN processing stages of CNN 2400 may still be performed evenif an early decision can be made. Moreover, the complexity of the firststage CNN 2405 a may vary based on different use cases, resourceavailability, and so forth.

If the early decision stage is unable to detect or classify the partialcompression data 2404 using the first stage CNN 2405 a, CNN 2400 mayproceed to a late decision stage, as shown in FIG. 24B. In the latedecision stage of FIG. 24B, for example, additional compression data2410 (e.g., motion prediction residuals) is evaluated using a secondstage CNN 2405 b to attempt to determine a late decision 2408.

Finally, for improved accuracy and/or in the event the late decisionstage is unsuccessful (e.g., the late decision stage is unable to detector classify the additional compression data 2410 using the second stageCNN 2405 b), CNN 2400 may proceed to a final decision stage, as shown inFIG. 24C. In the final decision stage of FIG. 24C, for example, thecompressed visual data 2402 may be fully decompressed using adecompression engine 2412, and the decompressed visual data 2414 (e.g.,pixel domain data) may then be evaluated using a final stage CNN 2405 cto determine a final decision 2416.

Accordingly, the collective stages of multi-domain cascade CNN 2400 aredepicted in FIG. 24C, where an early stage is used to generate an earlydecision based on an initial subset of compressed domain data, and laterstages are used to generate re-fined or final decisions based onadditional compressed domain data and eventually pixel domain data.

The described embodiments of multi-domain cascade CNN 2400 providenumerous advantages. First, visual data (e.g., images or video) does notneed to be fully decompressed before its contents can be analyzed usingdeep learning neural networks, thus reducing memory usage andcomputation typically required for decoding or decompressing the visualdata. Next, the cascading approach of CNN 2400 avoids the need totransmit certain compressed data to the cloud, such as when an earlydecision can be reached by an edge or fog node, thus improving bandwidthusage. Finally, a large portion of the overall analysis often occurs inthe early decision stage, which typically involves a simplified CNN ormachine learning model, thus reducing the overall computationalcomplexity.

FIGS. 25-31 illustrate the use of butterfly operations to implement amulti-domain convolutional neural network (CNN) that is capable ofprocessing both raw and compressed visual data.

As discussed above, many visual analytics systems require visual data tobe fully decompressed before any visual processing can be performed(e.g., using deep learning neural networks), which is an approach thatsuffers from various inefficiencies, including higher processinglatency, additional transmission bandwidth, and so forth. Accordingly,this disclosure presents various embodiments of a deep learning neuralnetwork that is capable of analyzing compressed visual data directly. Inparticular, the described embodiments present a multi-domain CNN thatuses butterfly operations to enable visual data processing in either thepixel domain or the compressed domain.

To illustrate, existing deep learning CNNs (e.g., inception or ResNetCNN models) typically repeat an inner module multiple times, and theinner module aggregates the results from multiple convolution layersand/or the original input at the end (analogous to a bottleneck). Forexample, FIGS. 25A-B illustrate a traditional 27-layer inception modelCNN 2500, and FIGS. 26 and 27 illustrate example inner modules 2600 and2700 for an inception model CNN. In particular, FIG. 26 illustrates aninner module 2600 implemented without dimension reduction, while FIG. 27illustrates an inner module 2700 implemented with dimension reduction.These CNN implementations are designed to process visual data in thepixel domain (e.g., raw or uncompressed visual data).

FIGS. 28 and 29, however, illustrate example CNN inner modules 2800 and2900 that use butterfly operations to enable multi-domain visual dataprocessing in either the pixel domain or the compressed domain.Butterfly operations, for example, are operations that can be used totransform compressed domain data (e.g., DCT domain data) back to thepixel domain. Accordingly, by incorporating butterfly layers into a CNN,the CNN can be provided with compressed visual data as its originalinput, and as the compressed data is processed by the successive CNNlayers, the compressed data is at least partially transformed ordecompressed back to the pixel domain using the butterfly layers in theCNN.

FIG. 28 illustrates an inner CNN module 2800 implemented withoutdimension reduction, while FIG. 29 illustrates an inner CNN module 2900implemented with dimension reduction. Moreover, as shown in theseexamples, additional butterfly layers or filters are added in parallelto the regular convolution layers. In some embodiments, for example, 2×2and/or 4×4 butterfly operations can be added in parallel to the regularconvolution and pooling layers. For example, in some embodiments, thebutterfly operations could be implemented similar to the examplebutterfly operation illustrated in FIGS. 31A-B.

With respect to inner module 2800 of FIG. 28, for example, butterflylayers 2830 a,b are added in parallel to convolution layers 2810 a-c andpooling layer 2820, and the butterfly layers 2830 include verticalN-point butterfly operations 2830 a and horizontal N-point butterflyoperations 2830 b. For example, in some embodiments, the butterflyoperations may be performed for both the vertical pixels and thehorizontal pixels. Similarly, with respect to inner module 2900 of FIG.29, butterfly layers 2930 a,b are added in parallel to convolutionlayers 2910 a-e and pooling layers 2920 a-b, and the butterfly layers2930 include vertical N-point butterfly operations 2930 a and horizontalN-point butterfly operations 2930 b.

Note that this approach, however, does not require multiple butterflylayers to be stacked within a single inner module, as the CNN does nothave to perform a complete inverse DCT. For example, the goal ofmultiple convolution layers is to extract/transform the input data to afeature space where the fully connected layers can easily separatedifferent clusters. Accordingly, the butterfly layers do not have toperform a complete inverse DCT, and instead, they can simply be designedto aid in extracting and transforming the input data into the featurespace. In this manner, a complete or entire stack or organized butterflylayers does not need to be included in the CNN.

Moreover, the weights of each butterfly can be adjusted during thetraining phase, and thus the decision of whether to use the butterflylayers and/or how much to rely on them will be adjusted automatically.

FIG. 30 illustrates an alternative embodiment of a multi-domain CNN 3000with butterfly layers 3002 and normal layers 3004 arranged sequentiallyrather than in parallel.

FIGS. 31A-B illustrate an example of a one-dimensional (1D) N-pointbutterfly operation. In particular, the illustrated example is a 4-pointbutterfly operation, meaning the butterfly operation is performed usingfour data points 3110 a-d. In other embodiments, however, butterflyoperations may be implemented using any number of data points. Moreover,in some embodiments, data points 3110 a-d may represent compressed pixeldata, such as DCT coefficients.

In some embodiments, the butterfly operation may be performed inmultiple stages. In each stage, for example, the butterfly operation maygenerate two outputs or channels using separate addition and subtractionoperations (e.g., by computing the sum of two points over a largedistance and the difference of two points over a large distance). Forexample, during a particular stage, the 1^(st) and 4^(th) points may beadded together to compute their sum (1^(st) point+4^(th) point), andalso subtracted to compute their difference (1^(st) point−4^(th) point).The points may then be shifted up cyclically and the process may berepeated for the next stage. For example, after each stage, the 4^(th)point becomes the 3^(rd) point, the 3^(rd) point becomes the 2^(nd)point, the 2^(nd) point becomes the 1^(st) point, and the 1^(st) pointbecomes the 4^(th) point. After the points are shifted, the next stageof the butterfly operation is performed by repeating the addition andsubtraction on the 1^(st) on 4^(th) points (e.g., using the new orderingof points).

In FIGS. 31A-B, for example, the addition and subtraction operations forthe first stage of a butterfly operation are shown. In particular, FIG.31A illustrates the addition operation, and FIG. 31B illustrates thesubtraction operation. In FIG. 31A, for example, the 1^(st) point (3110a) and the 4^(th) point (3110 d) are added together to compute a newpoint (3120 a) that represents their sum. Similarly, in FIG. 31B, the4^(th) point (3110 d) is subtracted from the 1^(st) point (3110 a) tocompute a new point (3130 d) that represents their difference. Thepoints are then shifted in the manner described above to perform thesubsequent stages of the butterfly operation.

Accordingly, the butterfly operations can be incorporated into a CNN inthis manner in order to enable processing of visual data in both thepixel domain and compressed domain (e.g., DCT domain), thus eliminatingthe requirement of fully decompressing visual data before analyzing itscontents using a deep learning neural network. For example, rather thanexplicitly performing an inverse DCT transform to fully decompressvisual data before processing it using a CNN, the CNN can instead beimplemented using butterfly layers to inherently incorporatedecompression functionality into the CNN, thus enabling the CNN to beprovided with compressed data as input.

FIGS. 32 and 33 illustrate an example embodiment of a three-dimensional(3D) CNN 3200 that is capable of processing compressed visual data. Insome embodiments, for example, 3D CNN 3200 could be used in theimplementation of, or in conjunction with, the compression-based CNNembodiments described throughout this disclosure (e.g., the CNNs ofFIGS. 24 and 28-31).

Many visual analytics systems require visual data to be decompressedbefore any processing can be performed, such as processing by a deeplearning neural network. To illustrate, FIG. 34 illustrates an exampleof a pixel-domain CNN 3400, and FIG. 35 illustrates an example of anassociated pixel-domain visual analytics pipeline 3500. In theillustrated example, pixel-domain CNN 3400 performs object detection andclassification for visual analytics using data in the pixel or imagedomain (e.g., using decompressed visual data). For example, theconvolutional kernels in the early layers of the CNN implementtwo-dimensional (2D) convolutions on the image data, and multiple layersof convolutions, pooling, and rectified linear unit (ReLU) operationsare repeated in order to successively extract combinations of featuresfrom the earlier layers. Moreover, because CNN 3400 operates onpixel-domain data, compressed visual data must be fully decompressedbefore it can be processed by CNN 3400. For example, as shown by visualanalytics pipeline 3500 of FIG. 35, the original pixel domain data 3502is first compressed by a video encoder 3510 (e.g., prior to transmissionover a network), and the compressed data 3504 is subsequentlydecompressed by a video decoder 3520 before performing video analytics3540 (e.g., using a CNN).

In the illustrated embodiment of FIGS. 32 and 33, however, 3D CNN 3200processes compressed visual data directly using a 3D format designed toimprove processing efficiency. For example, the input image may betransformed into the DCT domain and reshaped into a 3D format in orderto separate the DCT transform coefficients into different channels. Inthis manner, the reshaped DCT transform data is arranged in a mannerthat provides better correlation between the spatial and transformdomain coefficients. The reshaped DCT transform data can then beprocessed directly by a CNN (e.g., using 3D convolutions to performfeature extraction), which ultimately enables the CNN to be trainedfaster. For example, by eliminating the decompression step required byexisting approaches, processing efficiency is improved, particularly forcomputing environments that do not include built-in hardware videodecompression accelerators.

In some embodiments, for example, 3D CNN 3200 may be designed to operatedirectly on compressed visual data (e.g., video frames) represented inthe DCT domain using a 3D matrix. For example, in some embodiments, theDCT block indices may be represented by the x and y dimensions of the 3Dmatrix, while the DCT transform magnitude vectors may be organized alongthe z dimension. In this manner, the convolutional kernels in the firstlayer of the new CNN architecture can be implemented using 3D filtersdesigned to better capture the spatial and frequency domain correlationsand features of the compressed data, thus improving the performance ofthe CNN operation in the DCT domain.

The majority of common video and image encoding schemes use discretecosine transforms (DCT) to convert spatial pixel intensities tofrequency domain representations. The illustrated embodiment is based onthe observation that once image data is split into 4×4 pixel blocks andpassed through a transform such as DCT, the transformed data hasdifferent correlation properties than the original data. For example,with respect to a DCT transform, the DC coefficients of adjacent blocksare often strongly correlated, while the corresponding higher frequencyAC coefficients of adjacent blocks may be similarly correlated.

Accordingly, FIG. 32 illustrates an approach for transforming a 2D imageinto a 3D matrix of DCT data, which is arranged in a manner that allowsthe DCT data to be processed more efficiently by a CNN. In theillustrated example, an input image of size N×N (reference numeral 3210)is first broken up into 4×4 pixel blocks (example reference numeral3212), and each 4×4 pixel block is passed through a DCT transform. Theresulting DCT transform domain data (reference numeral 3220) is thenstored in a 3D matrix, where the x and y dimensions correspond to thespatial block indices and the z dimension contains vectors of DCTcoefficients (reference numeral 3222), which include 16 coefficients pervector. Accordingly, the resulting transform domain data (referencelabel 3220) has dimensions of size K×K×16, where K=N/4.

Next, as shown in FIG. 33, the transform domain data represented usingthe 3D matrix (reference label 3220) is input into the CNN (referencelabel 3200), which includes a first layer of 3D convolutional kernelsthat use 3D filters. This layer extracts both spatially correlatedfeatures in the x-y plane along with any specific signatures in thefrequency axis (z dimension), which can be used as input to succeedinglayers.

The illustrated embodiment provides numerous advantages, including theability to directly process compressed visual data in an efficientmanner, thus eliminating the need to decompress the data beforeanalyzing its contents (e.g., using a deep learning neural network). Inthis manner, the overall computational complexity of visual analyticscan be reduced. Moreover, because compressed or DCT domain data isquantized and thus represented using a more compact form than theoriginal visual data (e.g., video frame), the overall CNN complexity maybe further reduced compared to a conventional pixel-domain CNN. Forexample, with respect to visual data (e.g., images or video) compressedin certain compression formats such as JPEG or M-JPEG, the DCTcoefficients are quantized, and typically the highest frequencycomponents may be zeroed out by the quantization. Thus, the total volumeof non-zero data processed by the CNN is reduced compared to theoriginal image data. Accordingly, based on the data volume reduction ofthe compressed data (e.g., due to DCT coefficient quantization), the CNNcomplexity may be further reduced, and the training speed of convergencemay improve.

FIGS. 36 and 37 illustrate example embodiments of visual analyticspipelines 3600 and 3700 that perform visual analytics on compressedvisual data (e.g., using the compression-based CNN embodiments describedthroughout this disclosure). As shown by these FIGURES, the decoding ordecompression step in the visual analytics pipeline is optional and/ormay be omitted entirely. For example, as shown by visual analyticspipeline 3600 of FIG. 36, the original pixel domain data 3602 is firstcompressed by a video encoder 3610 (e.g., prior to transmission over anetwork), and the compressed data 3604 may optionally be partiallydecompressed by a video decoder 3620 before performing visual analytics3630 on the fully or partially compressed data 3606. Similarly, as shownby visual analytics pipeline 3700 of FIG. 37, the original pixel domaindata 3702 is first compressed by a video encoder 3710 (e.g., prior totransmission over a network), and visual analytics (e.g., imageclassification) 3720 is then directly performed on the compressed data3704.

FIG. 38 illustrates a performance graph 3800 showing the precision of aCNN trained using compressed visual data (e.g., 4×4 transform DCTinputs), such as the compression-based CNNs described throughout thisdisclosure.

FIG. 39 illustrates a flowchart 3900 for an example embodiment ofcontext-aware image compression. In some embodiments, flowchart 3900 maybe implemented using the embodiments and functionality describedthroughout this disclosure.

Today, many people rely on the cloud for storing or backing up theirphotos. Typically, photos are stored as individually compressed files orunits. In the current computing era, however, that approach is ofteninefficient. For example, people increasingly use their mobile devicesto take photos, and each new generation of mobile devices are updatedwith cameras that support more and more megapixels, which results inlarger volumes of photos that require more storage space. Moreover,people often capture multiple photos of the same object or scene duringa single occasion, which often results in a close temporal correlationamong those photos, along with substantial redundancy. Accordingly, dueto the redundancy across similar photos, individually compressing andstoring each photo can be an inefficient approach. For example,traditionally, each photo is compressed and saved independently using aparticular image compression format, such as JPEG. By compressing eachphoto individually, however, current approaches fail to leverage theinter-picture correlations between groups of similar photos, and thusmore storage space is required to store the photos. For example, twophotos that are nearly identical would still require double the storageof a single photo.

Accordingly, in the illustrated embodiment, groups of similar or relatedphotos are compressed and stored more efficiently. For example, contextinformation associated with photos is extracted and used to identifysimilar or related photos, and similar photos are then compressedjointly as a group. The contextual information, for example, could beused to identify a group of pictures from a single user that were takenvery close in time and/or at the same location. As another example, thecontextual information could be used to identify a group of picturestaken by different users but at the same location. Accordingly, theidentified group of similar photos may be compressed using video codingin order to leverage the inter-photo correlations and ultimatelycompress the photos more efficiently. In this manner, compressingrelated or correlated images using video compression rather thanstandard image compression can significantly reduce the storage spacerequired for the photos (e.g., 2-5 times less storage space in somecases). Accordingly, this approach can be used to save or reduce storagein the cloud.

The flowchart may begin at block 3902 by first obtaining a new photo. Insome cases, for example, the new photo could be captured by the cameraof a mobile device. In other cases, however, any type of device orcamera may be used to capture the photo.

The flowchart may then proceed to block 3904 to collect contextinformation associated with the new photo. For example, when a photo isnewly captured (e.g., by a mobile device), corresponding contextinformation associated with the photo is collected, such as a timestamp,GPS coordinates, device orientation and motion states, and so forth.

The flowchart may then proceed to block 3906 to determine if a matchingmaster photo can be identified for the new photo. In some embodiments,for example, the context information of the new photo is compared to thecontext information of other previously captured master photos todetermine whether the new photo is closely correlated to any of theexisting master photos. For example, if the photo is taken in the samelocation, within a certain amount of time, and with little phonemovement compared to a master photo, it is likely that the new photo ishighly correlated with the master photo. Further, in some embodiments,image feature matching techniques can then be applied to confirm thephoto correlation. In some embodiments, for example, a scale-invariantfeature transform (SIFT) may be used to determine whether a pair ofphotos are sufficiently correlated or matching.

If a matching master photo is identified at block 3906, the flowchartmay then proceed to block 3908 to encode the new photo with the matchingmaster photo. In some embodiments, for example, a video codec (e.g.,H.264) may be used to compress the new photo as an inter-frameassociated with the master photo. For example, video codecs typicallyprovide inter-frame encoding, which effectively utilizes the temporalcorrelation between similar images to improve the coding efficiency.

In some embodiments, a master photo may include any photo that iscompressed without reference to other parent or related images, while aslave photo may include any photo that is compressed with reference to amaster or parent image (e.g., using inter-frame mode of a video codec).Accordingly, a slave photo must efficiently record or correlate relevantinformation of its master photo, so that when the slave photo needs tobe decoded for display of the entire image, the associated master photocan be quickly identified.

If a matching master photo is NOT identified at block 3906, theflowchart may then proceed to block 3910 to encode the new photo byitself. For example, when the new photo does not match any of theexisting master photos, the new photo is encoded without referencing anyother photos, and the flowchart may then proceed to block 3912 todesignate the new photo as a master photo, allowing it to potentially becompressed with other subsequently captured photos.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 3902 to continue obtaining and compressing newly captured photos.

Privacy/Security

In distributed visual processing systems, it is important to implementeffective privacy and security policies to protect sensitive visual dataof underlying users or subjects (e.g., images or video with people'sfaces). Accordingly, in some embodiments, the visual fog architecturedescribed throughout this disclosure may be implemented using a varietyof privacy and security safeguards.

In some embodiments, for example, privacy-preserving distributed visualprocessing may be used in order to schedule or distribute visionworkloads across available fog nodes in an efficient manner, while alsoadhering to any applicable privacy and/or security constraints.

Similarly, a multi-tiered storage approach may be used to store visualdata in different locations and/or for different durations of time,depending on the particular level of sensitivity of the data. Forexample, the cloud may be used for long term storage of less sensitiveor high-level visual data or metadata, while edge devices (e.g., onpremise gateways) may be used for storage of highly sensitive visualdata.

Moreover, certain vision operations may be implemented usingprivacy-preserving approaches. For example, for some vision applications(e.g., automated demographics identification), feature extraction andrecognition may be implemented using cameras and sensors that capturetop-down views rather than intrusive frontal views.

As another example, gateway cloud authentication may be used to securelyauthenticate gateways and/or other fog devices to the cloud using JSONweb tokens.

As another example, wallets or distributed keys, along with MESH orGOSSIP based communication protocol, can be used to provide improved andmore secure key management solutions.

Stream multiplexing may be used in application layer routing forstreaming media, for example, by multiplexing visual sensors overmultiple channels and introducing entropy to make channel predictionmore difficult. For example, additional security can be provided byintroducing entropy and other noise (e.g., chaff signals) designed tocomplicate channel prediction, thus thwarting efforts of maliciousactors to pick up on video feeds.

As another example, a self-sovereign blockchain can be used to providemulti-tenant device identification. For example, the blockchain can beused to handle the orchestration and acceptance of device identitiesacross multiple visual fog networks (e.g., even for legacy systems),thus allowing devices to assert their identity without relying on thirdparty or centralized services. A self-sovereign blockchain can similarlybe used for other purposes, such as managing a collection of distributedcomputing algorithms.

As another example, blockchain lifecycle management (e.g., managing theinstantiation and lifecycle of blockchains) can be used to provide anadditional level of security on blockchains used in a visual fogarchitecture. For example, blockchain lifecycle management can be usedto ensure that a particular blockchain is implemented correctly andbehaves as expected.

As another example, stakeholder management can be used to provide a setof protocols and frameworks to allow self-interests to be asserted,while arbitrating against conflicts in an equitable way.

FIGS. 40A-C illustrate an example embodiment of a privacy-preservingdemographic identification system 4000. Identifying human demographicattributes (e.g., age, gender, race, and so forth) can be leveraged fora variety of use cases and applications. Example use cases includehuman-computer interaction, surveillance, business and consumeranalytics, and so forth. In retail and healthcare segments, for example,defining a target audience and developing customer profiles has become acritical factor for successful brand strategy development.

In some embodiments, for example, computer vision and/or facialrecognition technology may be used to identify human demographics. Forexample, demographics could be identified based on frontal and/or sidefacial features extracted using computer vision facial recognitiontechnology. The use of frontal facial recognition technology in public,however, may implicate potential privacy concerns. Moreover, demographicidentification is crucial across different domains and should not belimited to only frontal-based sensors and recognition techniques,particularly in the Internet-of-Things (IoT) era, which is projected tohave over 20 billion connected devices by year 2020. Further, whenlimited to frontal-based vision sensors, it may be challenging todevelop a demographics identification system that overcomes the personocclusion problem, while also providing wide processing viewing angles.

Accordingly, in the illustrated embodiment of FIGS. 40A-C,privacy-preserving demographic identification system 4000 uses one ormore top-view sensors 4015 to identify human demographics. In someembodiments, for example, either a single sensor 4015 or multiplesensors 4015 may be used to capture top-down views of humans, ratherthan conventional frontal views. Moreover, human demographics may thenbe identified based on features extracted from the top-down viewscaptured by the sensors 4015. In this manner, the use of top-viewsensors 4015 enables human demographics to be automatically identifiedwhile preserving privacy, providing wider sensor viewing angles, andreducing susceptibility to occlusion.

FIG. 40A illustrates a high-level implementation of demographicidentification system 4000. In the illustrated embodiment, edge devices4010 include multiple sets of top-view sensors 4015 a-c that are usedfor sensing humans. For example, each set of top-view sensors 4015 a-cmay include one or more sensors that are capable of capturinginformation about their surrounding environment. The informationcaptured by top-view sensors 4015 a-c is then processed in the fog 4020to detect humans and identify their demographics. The contextualinformation extracted by the fog 4020 (e.g., human demographics) maythen be transmitted to the cloud 4030 for further analytics, such aspeople profiling or generating heat maps.

FIG. 40B illustrates an example of a set of top-view sensor(s) 4015associated with demographic identification system 4000 of FIG. 40A. Asshown in the illustrated example, top-view sensors 4015 include acollection of one or more sensors positioned above an area that isaccessible to humans 4002. In some embodiments, for example, top-viewsensors 4015 could be mounted to the ceiling of a retail store near theentrance. Moreover, top-view sensors 4015 can include any type and/orcombination of sensor(s), such as a vision camera, infrared camera,light detection and ranging (LiDAR) sensor, and so forth. In thismanner, top-view sensors 4015 can be used to capture top-viewrepresentations of humans 4002 that pass below the sensors. Moreover, asdescribed further with respect to FIG. 40C, the top-view representationscaptured by top-view sensors 4015 can then be processed further toidentify the demographics of humans 4002 captured by the sensors.

FIG. 40C illustrates an example of the demographics identificationprocess performed by the fog 4020 in demographic identification system4000 of FIG. 40A. In the illustrated example, the demographicsidentification process involves (i) training a demographicsclassification model, and (ii) identifying demographic information usingthe trained demographics classification model with top-view sensor dataas input.

The process of training the demographics classification model isillustrated by blocks 4021-4024. At block 4021, a training database oftop-view human data must first be obtained or generated. In someembodiments, for example, the training database may include datacaptured by top-view sensors 4015, such as camera images, infraredimages, point clouds, and so forth. At block 4022, features that aretypically representative of human demographics are then selected/trainedfrom the database using feature extraction methodologies, such asprincipal component analysis (PCA), discrete cosine transforms (DCT),machine learning (e.g., deep learning using a neural network), and soforth. At block 4023, the selected/trained features are then provided asinput to a process used to train a demographics classification model. Atblock 4024, the trained demographics model is then saved in the fog 4020for subsequent use during the demographics identification process, asdescribed further below.

The process of identifying human demographics is illustrated by blocks4025-4029. At block 4025, sensor data is captured by edge devices 4010using one or more top-view sensor(s) 4015, such as a vision camera,infrared camera, LiDAR sensor, and so forth. The raw sensor data (e.g.,RGB images, thermal images, point clouds) is then transmitted from theedge 4010 to the fog 4020 in order to perform data pre-processing in thefog 4020 (e.g., on-premises), such as data transformations, de-noising,and so forth. At block 4026, person detection is then performed on thepre-processed input stream. In some embodiments, for example, thepre-processed input stream is analyzed to determine if a person iscaptured in the underlying visual data. As an example, pre-processedimage data from a top-view camera may be analyzed to determine if theimage contains a person, and if so, the portion of the image thatcontains the person may be extracted. At block 4027, features that aretypically representative of human demographics are then selected orextracted from the detected person using feature extraction/machinelearning techniques. At block 4028, the extracted features from block4027 and the pre-trained demographics model from block 4024 are thenused by a demographics classifier to classify the demographic attributesof the detected person. At block 4029, demographic informationassociated with the detected person is then identified based on theoutput of the demographics classifier.

The described embodiments of top-view demographics identificationprovide numerous advantages. As an example, the described embodimentsenable demographic information to be accurately identified based ontop-down views of humans captured using a single- or multi-sensorapproach. Compared to a frontal view approach, for example, a top-downor aerial perspective provides a wider angle of view for processing,reduces the problem of blocking or occlusion of people captured by thesensors, and preserves depth information associated with people andfeatures captured and processed by the system. In addition, thedescribed embodiments are less privacy-intrusive, as they only capturetop views of people rather than other more intrusive views, such asfrontal views. The described embodiments also identify demographicinformation based on permanent or lasting anthropometry features ratherthan features that may change or vary. Moreover, unlike motion-baseddetection approaches, the described embodiments are operable using onlystatic views or images and do not require continuous image sequences orvideos. Further, the described embodiments can be leveraged for avariety of use cases and applications, including retail, digitalsurveillance, smart buildings, and/or other any other applicationsinvolving human sensing, person identification, person re-identification(e.g., detecting/tracking/re-identifying people across multiplemonitored areas), and so forth.

FIG. 53 illustrates a flowchart 5300 for an example embodiment ofprivacy-preserving demographics identification. In some embodiments, forexample, flowchart 5300 may be implemented by demographicsidentification system 4000 of FIGS. 40A-C.

The flowchart may begin at block 5302 by obtaining sensor data from atop-view sensing device. A top-view sensing device, for example, may beused to capture sensor data associated with the environment below thetop-view sensing device (e.g., from a top-down perspective). In someembodiments, the top-view sensing device may include a plurality ofsensors, including a camera, infrared sensor, heat sensor, laser-basedsensor (e.g., LiDAR), and so forth.

The flowchart may then proceed to block 5304 to perform preprocessing onthe sensor data, such as data transformations, filtering, noisereduction, and so forth. In some embodiments, for example, the rawsensor data may be transmitted to and/or obtained by a processor that isused to perform the preprocessing. For example, the preprocessing may beperformed by an edge processing device at or near the network edge(e.g., near the top-view sensing device), such as an on-premise edgegateway.

The flowchart may then proceed to block 5306 to generate a visualrepresentation of the environment below the top-view sensing device. Thevisual representation, for example, may be generated using the sensordata captured by the top-view sensing device (e.g., camera images,infrared images, point clouds, and so forth). In some embodiments, forexample, the visual representation may be a three-dimensional (3D)representation or mapping of the environment from a top-downperspective. Moreover, in some embodiments, the visual representationmay be generated at or near the network edge (e.g., near the top-viewsensing device). For example, in some embodiments, an edge processingdevice (e.g., an on-premise edge gateway) may be used to generate thevisual representation.

The flowchart may then proceed to block 5308 to determine whether aperson is detected in visual representation. For example, if a personwas located under the top-view sensing device when the sensor data wascaptured, then the visual representation generated using the sensor datamay include a representation of the person from a top-view perspective.Accordingly, the visual representation may be analyzed (e.g., usingimage processing techniques) to determine whether it contains a person.In some embodiments, for example, the person detection may be performedat or near the network edge (e.g., near the top-view sensing device) byan edge processing device (e.g., an on-premise edge gateway).

If it is determined at block 5308 that a person is NOT detected in thevisual representation, the flowchart may proceed back to block 5302 tocontinue obtaining and processing sensor data until a person isdetected.

If it is determined at block 5308 that a person is detected in thevisual representation, however, the top-view representation of theperson may be extracted from the visual representation, and theflowchart may then proceed to block 5310 to identify one or morefeatures associated with the person. In some embodiments, for example,the top-view representation of the person may be analyzed to identify orextract anthropometric features associated with the person (e.g.,features or measurements associated with the size and proportions of theperson). For example, in some embodiments, the anthropometric featuresmay be identified by performing feature extraction using an imageprocessing technique, such as a discrete cosine transform (DCT),principal component analysis (PCA), machine learning technique, and soforth. Moreover, in some embodiments, the feature identification orextraction may be performed at or near the network edge (e.g., near thetop-view sensing device) by an edge processing device (e.g., anon-premise edge gateway).

The flowchart may then proceed to block 5312 to identify demographicinformation associated with the person (e.g., age, gender, race) basedon the identified features. In some embodiments, for example, a machinelearning model may be trained to recognize demographic information basedon human anthropometric features. In this manner, the machine learningmodel can be used to classify the identified features of the person torecognize the associated demographic information.

In some embodiments, the demographics identification may be performed ator near the network edge (e.g., near the top-view sensing device) by anedge processing device (e.g., an on-premise edge gateway). Moreover, insome embodiments, the edge processing device may transmit thedemographics information (e.g., using a communication interface) to acloud processing device to perform further analytics, such as generatinga heat map or a people profile.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 5302 to continue obtaining and processing sensor data from atop-view sensing device.

FIGS. 41-43 illustrate an example embodiment of privacy-preservingdistributed visual data processing.

In visual computing, multi-target multi-camera tracking (MTMCT) andtarget re-identification (ReID) are some of the most common workloadsacross different use cases. MTMCT involves tracking multiple objectsacross multiple views or cameras, while ReID involves re-identifying anobject (e.g., by extracting robust features) even after the objectundergoes significant changes in appearance. For example, in retail,MTMCT is often used to track shoppers within a store, while ReID may beused to extract and summarize robust features of shoppers so they canlater be re-identified (e.g., using MTMCT) in different circumstances,such as when a shopper has a significant change in appearance or visitsa different store.

Currently, there are no coherent end-to-end (E2E) solutions forperforming MTMCT and ReID that are scalable to large-scale visualcomputing systems (e.g., with tens of thousands of camera streams ormore). In particular, bandwidth limitations render it challenging todeploy such a system in a conventional cloud computing paradigm wherecameras send continuous video streams to the cloud for processing. Forexample, due to the large volume of video data generated by suchsystems, it is not feasible to funnel all of that data to the cloud forprocessing. On the other hand, it is unlikely that edge devices near thesource of the video data are capable of processing a complete visualprocessing workload in real time.

Moreover, privacy is also a challenge in scaling out such a system, assending visual data to the cloud for processing may implicate privacyconcerns. For example, in order to preserve customer privacy, manyretailers will not allow any video or images to be transmitted out oftheir stores.

Accordingly, FIGS. 41-43 illustrate an embodiment that solves theproblem of scaling out visual computing systems with MTMCT and ReIDcapabilities in a privacy-preserving manner. The illustrated embodimentpresents an edge-to-edge (E2E) architecture for performing MTMCT andReID across edge devices, gateways, and the cloud. The architecture isscalable and privacy-preserving, and can be easily generalized to manyvertical applications or use cases, such as shopper insights in retail,people searching in digital security and surveillance, player trackingand replays in sports, and so forth.

In some embodiments, for example, vision workloads may be scheduled andexecuted across visual fog nodes based on specified privacy constraints.As an example, privacy constraints for an MTMCT and/or ReID workload mayrequire tasks that output pictures with faces to remain on-premises(e.g., neither the tasks nor their output are assigned or transmittedbeyond the premise or to the cloud), be anonymized (e.g., face-blurred),and/or be deployed only on devices with enhanced link security.

In some embodiments, for example, rather than funneling every bit ofvisual data to the cloud for processing, intelligent decisions can bemade regarding how visual data and workloads are processed anddistributed across a visual computing system. Based on the privacyrequirements of a particular visual application, for example, a privacyboundary can be defined within the end-to-end paradigm of a visualcomputing system in order to achieve performance efficiency while alsopreserving privacy.

In some embodiments, for example, job partitioning can be used topartition a visual analytics workload into a directed acrylic graph(DAG) with vertices that represent primitive visual operations and edgesthat represent their dependencies. In this manner, the graph can be usedto represent the various tasks and associated dependencies for aparticular workload. Moreover, a privacy policy can be definedseparately for each dependency. Similarly, a device connectivity graphcan be used to represent the various devices and their connectivity inthe edge-to-cloud paradigm, and a privacy level agreement (PLA) can beestablished for each edge of connectivity in the graph. In this manner,the edge-to-cloud architecture can be implemented to include a coherentmanagement interface that performs end-to-end workload distributionwithout compromising privacy. For example, using the job partitioningapproach described above, workload distribution effectively becomes amapping problem of assigning the tasks of a workload onto devices in theedge-to-cloud paradigm. In some embodiments, for example, a globalscheduler can be used to determine an optimal mapping between tasks anddevices in order to maximize performance while preserving privacyconstraints.

FIG. 41 illustrates an example visual workload graph 4100 for performingMTMCT and ReID. Example workload 4100 includes a plurality of tasks,including preprocessing 4102, detection 4104, tracking 4106, matching4108, and database access 4110. Further, the dependencies between thesevarious tasks are represented by the solid and dotted lines in theillustrated example. Moreover, the solid lines represent unrestrictedaccess or transmission of the original visual data, while the dottedlines represent restricted or privacy-preserving access or transmission(e.g., transmitting only visual metadata, such as feature vectors). Inthis manner, a privacy policy can be defined for the workload, forexample, by specifying whether each task has unrestricted access orrestricted access to the original visual data.

FIG. 42 illustrates an example of an edge-to-cloud device connectivitygraph 4200. In the illustrated example, graph 4200 illustrates theconnectivity between various devices of a 3-tier edge-to-cloud network,which includes cameras 4210 a-c, gateways 4220 a-b, and the cloud 4230.In particular, the device connectivity is illustrated for bothedge-to-cloud communications (e.g., camera to gateway to cloud) as wellas peer-to-peer communications (e.g., gateway-to-gateway). Moreover, theconnectivity between the respective devices is represented using solidand dotted lines. For example, the solid lines represent high-securityconnectivity links, while the dotted lines represent limited-securityconnectivity links. In this manner, a privacy policy or privacy levelagreement (PLA) can be defined for an edge-to-cloud paradigm, forexample, by specifying the requisite security for each edge ofconnectivity in the graph.

FIG. 43 illustrates a privacy-preserving workload deployment 4300. Inparticular, workload deployment 4300 illustrates an example deploymentof the workload 4100 of FIG. 41 on edge-to-cloud network 4200 of FIG.42.

In the illustrated example, privacy is treated as an explicit constraintwhen performing task-to-device mapping to deploy the workload. In someembodiments, for example, workloads can be represented in linear formsto enable the mapping problem to be solved efficiently using state ofthe art integer linear programming (ILP) solvers.

In some embodiments, for example, when scheduling a particular workloadon an edge-to-cloud network, the workload and the edge-to-cloud networkmay each be represented using a graph, such as a directed acrylic graph(DAG). For example, the workload and its underlying tasks may berepresented by a workload or task dependency graph G_(T)=(V_(T), E_(T)),where each vertex v∈V_(T) represents a task, and each edge (u, v)∈E_(T)represents a dependency between task u and task v. Similarly, theedge-to-cloud network may be represented by a network or deviceconnectivity graph GD=(V_(D), E_(D)), where each vertex v∈V_(D)represents a device in the network, and each edge (u, v)∈E_(D)represents the connectivity from device u to device v.

Moreover, the privacy policy (PP) for each task dependency in theworkload graph may be defined using a PP function p: E_(T)→

, such that the smaller the number (N), the more vulnerable the datatransmission. Similarly, the privacy level agreement (PLA) for eachconnectivity link in the device connectivity graph may be defined usinga PLA function s: E_(D)→

, such that the smaller the number (

), the more secure the link.

In this manner, based on the privacy policy (PP) and privacy levelagreement (PLA) functions, a privacy constraint (PC) can be defined ass(d)≤p(e), ∀e∈E_(T), d∈f(e), where f: E_(T)→x_(i=0) ^(k)E_(D) is themapping function from a particular workload to the edge-to-cloudparadigm. Essentially, f maps an edge in a workload graph to a path inan edge-to-cloud connectivity graph. For example, in the context ofvisual fog computing, f is a scheduling function that determines theparticular fog devices that the tasks of a workload should be assignedto, along with the particular network connectivity links between pairsof fog devices that should be used for the data transmissions.Accordingly, the above privacy constraint (PC) requires the privacylevel agreement (PLA) of a particular connectivity link to be capable ofaccommodating the privacy policy (PP) of a particular data transmissionsent over that connectivity link. For example, in some embodiments, adata transmission of PP level 1 (unrestricted access) can only map to alink of PLA level 1 (high security), while a data transmission of PPlevel 2 (privacy-preserving) can map to connectivity links of PLA level1 (high security) and PLA level 2 (limited security).

Moreover, in some embodiments, a visual fog schedule that adheres to theabove privacy constraint (PC) can be determined using integer linearprogramming (ILP). Integer linear programming (ILP) is a mathematicaloptimization or feasibility technique for solving or optimizing amathematical model represented by linear relationships. In particular,ILP can be used to optimize a linear objective function, subject toadditional linear equality and linear inequality constraints. In somecases, for example, an ILP problem can be expressed as follows:

-   -   minimize: c^(T)x (objective term)    -   subject to: Ax≤b (inequality constraint)        -   Cx=d (equality constraint)    -   and: x∈{0, 1}^(K) (binary constraint).

Moreover, this ILP model can be used to determine an optimal schedule fthat satisfies a specified objective (e.g., total network utilization),while also adhering to other additional constraints, such as a privacyconstraint and any other device, network, or mapping constraints. Forexample, when using the example ILP model above to perform visual fogscheduling, x presents the collection of possible schedules f, K is thelength of x, the objective term presents a scheduling objective to beminimized (e.g., total network utilization), and the inequality/equalityconstraints present any additional constraints, such as device, network,mapping, and/or privacy constraints. The above privacy constraint (PC),for example, can be presented as an inequality constraint of the ILPproblem.

FIG. 54 illustrates a flowchart 5400 for an example embodiment ofprivacy-preserving distributed visual processing. In some embodiments,for example, flowchart 5400 may be implemented using the visualcomputing embodiments described throughout this disclosure (e.g., theprivacy-preserving distributed visual processing techniques of FIGS.41-43 and/or the visual computing architecture described throughout thisdisclosure).

The flowchart may begin at block 5402 by identifying a new workload. Insome embodiments, for example, the new workload may include a pluralityof tasks associated with processing sensor data captured by one or moresensors. For example, in some embodiments, the sensor data may be visualdata captured by one or more vision-based sensors (e.g., a camera,infrared sensor, and/or laser-based sensor).

The flowchart may then proceed to block 5404 to generate a workloadgraph based on the workload. In some embodiments, for example, theworkload graph may include information associated with the underlyingtasks of the workload, along with the task dependencies among thosetasks.

The flowchart may then proceed to block 5406 to generate or identify adevice connectivity graph. In some embodiments, for example, the deviceconnectivity graph may include device connectivity informationassociated with a plurality of processing devices, such as edge, cloud,and/or intermediary network processing devices. The device connectivityinformation, for example, may include information associated with thedevice connectivity links among the plurality of processing devices.

The flowchart may then proceed to block 5408 to identify a privacypolicy associated with the workload and/or its underlying tasks. In someembodiments, for example, the privacy policy may comprise privacyrequirements associated with the task dependencies among the workloadtasks.

The flowchart may then proceed to block 5410 to identify privacy levelinformation associated with the plurality of processing devices. In someembodiments, for example, the privacy level information may includeprivacy levels provided by the device connectivity links among theplurality of processing devices. Moreover, in some embodiments, theprivacy level information may be specified by a privacy level agreement.

The flowchart may then proceed to block 5412 to identify a privacyconstraint for workload scheduling based on the privacy policy and theprivacy level information. In some embodiments, for example, the privacyconstraint may require the privacy level of a particular connectivitylink to be capable of accommodating the privacy policy of any taskdependency mapped to that connectivity link for data transmission.

The flowchart may then proceed to block 5414 to determine a workloadschedule. The workload schedule, for example, may include a mapping ofthe workload onto the plurality of processing devices. Moreover, in someembodiments, the workload schedule may be determined based on theprivacy constraint, the workload graph, and the device connectivitygraph. For example, in some embodiments, the workload schedule may bedetermined by solving an integer linear programming model based on theprivacy constraint, the workload graph, and the device connectivitygraph (e.g., as described in connection with FIGS. 41-43). In thismanner, a resulting workload schedule is determined in a manner thatadheres to the privacy constraint. Moreover, in some embodiments, amachine learning model may be used to optimize privacy-constrainedworkload scheduling.

In some embodiments, the resulting workload schedule may then bedistributed to the plurality of processing devices (e.g., via acommunication interface) in order to execute the workload.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 5402 to continue scheduling new workloads.

FIGS. 44-46 illustrate example embodiments of self-sovereign deviceidentification for distributed computing networks. In some embodiments,for example, a fog node (e.g., IoT sensor, actuator, camera, controller,gateway, and/or any other type of fog node) may be a “multi-tenant” nodethat is capable of participating in multiple different distributedcomputing networks (e.g., visual fog networks). Moreover, certainnetworks may require a new fog node to be “on-boarded” or “commissioned”before the fog node is allowed to access each network (e.g., using theonboarding/commissioning protocols of the Open Connectivity Foundation(OCF) and/or Intel's Secure Device Onboard (SDO) technology). Manyvisual computing solutions, however, may assume that ownership of a nodeis singular, meaning each node has only one owner. Accordingly,ownership disputes may arise from a multi-tenant fog node'sparticipation in multiple fog networks. The true or original owner of amulti-tenant fog node, however, has an interest in avoiding theseownership disputes. Accordingly, many visual computing solutions areunsuitable for multi-tenant fog nodes, which may participate in multiplefog networks while also abiding by each network's onboarding orcommissioning protocols (e.g., as defined by OCF or Intel SDO).

Accordingly, in the illustrated embodiments, a multi-tenant fog node canuse a self-sovereign device identity in order to allow the node owner toretain an assertion of ownership even when the fog node participates in,or roams to, other fog networks. In some embodiments, for example, aself-sovereign identity blockchain may be used to register theidentities of fog nodes or devices. A blockchain, for example, may be adynamic list of records or blocks that are linked and/or secured usingcryptographic approaches. In some embodiments, for example, each blockin a blockchain may include a hash pointer linking to a previous block,a timestamp, transaction data, and so forth. Accordingly, in someembodiments, a blockchain can be used as a distributed ledger forrecording transactions in an efficient, verifiable, and/or permanentmanner. In visual computing, for example, before adding a deviceidentifier for a new fog node, a blockchain may optionally be used toverify that the identifier has not been previously asserted by anothernode. Further, the public key used to verify the device identity of thefog node may also be contributed to the blockchain, allowing the deviceto later prove it is the rightful owner of its identity.

FIG. 44 illustrates an example embodiment of a distributed computingarchitecture 4400 with multi-tenant device identification. In theillustrated embodiment, architecture 4400 includes fog networks A and B4410 a-b, self-sovereign identity blockchain 4420, and new fog device4430, as described further below.

A new fog device 4430 that is seeking to be used in multiple fognetworks 4410, but is not exclusive to any particular fog network, maynot have sufficient resources or capabilities to create and maintainvirtual sandbox environments for each of the fog networks. Moreover,each fog network 4410 may have a large set of its own local fog devicesthat are exclusive to that network and do not roam into other fognetworks. Accordingly, reusing device identifiers may not pose asignificant problem of duplicative identifiers until a new device 4430with a conflicting identity roams into a particular fog network.

There is often a cost associated with changing the identity of a device,however, as credentials, access tokens, and application logic may belinked to the device identity. Moreover, the respective owners ofdevices with conflicting identifies have a self-interest in resolvingthe conflict (e.g., to avoid ownership disputes), but without bearingthe cost. For example, the conflicting devices may respectively vieweach other as “foreign,” and thus each device may want the other“foreign” device to bear the cost of an identity change. Accordingly, toresolve the opposing self-interests of devices with conflictingidentities, a blockchain 4420 may be used to provide a fair algorithmfor giving preference to a device for its use of an identity. In someembodiments, for example, the device that first registered a particularidentity with the blockchain 4420 is given preference in the event of aconflict.

FIG. 45 illustrates an example call flow 4500 for performing nameregistration of a self-sovereign device identity. In some embodiments,for example, registration of a self-sovereign device identity may beperformed before onboarding a new fog device onto a visual fog network.For example, prior to being on-boarded onto a visual fog network, a fogdevice may register its choice of device identity with a blockchain.

Moreover, the blockchain may have a policy for preventing duplicativeidentity registrations, for example, by first checking for duplicatesand only allowing registration if no duplicates exist. For example,duplicative identity detection may be performed by blockchain processingnodes as a requirement for vetting transaction blocks used for identityregistration. In the illustrated call flow 4500, for example, each nodeperforms the following steps:

(1) receive transaction request from new device: TX_(n+1)={S1, “A71C3”}, where S1=Sign_K_(alice)(“A71C3”);

(2) compute hash H1=SHA256(“A71C3”);

(3) search hash tree of transaction attributes, whereB_(x-poss)=Search(TxTree, H1);

(4) IF B_(x-poss)=“H1” THEN return ERROR_DUP_FOUND;

(5) ELSE IF B_(x-poss)=“ ” THEN add TX_(n+1) to the current block whereCurrentBlock=[TX_(n+1), TX_(n), TX_(n−1), . . . , TX_(n−m)];

(6) compute new current block hash BH=SHA256([TX_(n+1), TX_(n),TX_(n−1), . . . , TX_(n−m)]);

(7) write BH to the blockchain at B_(curr-pos)(current position); and

(8) insert the tuple (H1, BH, B_(x-poss)) into TxTree.

In some embodiments, however, a less restrictive policy may be used,such as a policy that does not check for duplicates during identity orname registration, and instead relies on dispute resolution to resolveduplicative identities. For example, at the time a device is on-boardedonto a new fog network, the blockchain can be consulted to determine ifthe identifier has previously been used, and if so, conflict resolutioncan be performed. The advantages of a less restrictive policy includeimproved performance and the ability to support mass registrationworkloads, among other examples.

FIG. 46 illustrates an example call flow 4600 for conflict resolution ofself-sovereign device identities. In some circumstances, for example, itmay be unnecessary to verify that a new device identifier is globallyunique at the time of registration, and instead, conflicting identitiesmay be addressed when a new device is on-boarded onto a local fognetwork and an existing device already has the same identity.Accordingly, in some embodiments, conflicting device identities on aparticular fog network may be resolved using conflict resolution callflow 4600. In the illustrated call flow 4600, for example, a blockchainis used to resolve conflicts based on identity registration priority(e.g., the first device that registered a duplicative identity with theblockchain receives preference). Accordingly, this approach does notrequire device identifiers to be globally unique, but in the eventmultiple devices on the same fog network have the same identity, itrequires one of the devices to select a different identifier wheninteracting with that particular network. Moreover, the dispute overwhich device should pay the cost of changing its identity is resolvedusing the blockchain. By way of comparison, FIG. 47 illustrates anexample of device onboarding or commissioning in a visual fog networkwithout employing conflict resolution.

In this manner, based on the illustrated embodiments of FIGS. 44-46,device identity assertion can be performed at any time duringmanufacturing of a device, such as a system-on-a-chip (SoC) or any othertype of computing chip, circuit, or device. Moreover, rather than anassertion of device “ownership,” device identity assertion involves anassertion of identity ownership, where the device is the owner of theidentity. Accordingly, any appropriate entity within the supply chain ofa particular device (e.g., an original design manufacturer (ODM),original equipment manufacturer (OEM), distributor, retailer,value-added reseller (VAR), installer, or end customer) may assert theidentity of a device based on the sophistication and capability of theparticular entity.

FIGS. 48 and 49 illustrate example embodiments of algorithmidentification for distributed computing using a self-sovereignblockchain.

Distributed computing interoperability depends on agreement amongparticipating nodes regarding the particular algorithms used to processinformation at each node. In some cases, for example, algorithmagreement among nodes may depend on a central authority that manages aregistry or database of algorithm identifiers. In this manner,distributed nodes must rely on the registry for selection of theappropriate algorithms, otherwise interoperability is not achieved.

This dependence on central authorities can lead to service disruptions,however, such as when a registry goes offline, a registry is slow topublish new algorithm identifiers (e.g., thus slowing the pace at whichnew algorithms can be deployed), a central authority becomes the targetof politicizations (e.g., registration requests are held in ransom forprocessing fees, political favors, and/or other forms of manipulationthat are not tied to the economics of the distributed computingapplication), and so forth. For example, these approaches are oftenhighly centralized and may involve international or governmentalinstitutions, which may be prone to politicizations and/or governmentregulation (e.g., net neutrality). Moreover, since agreement on whichalgorithms to use is fundamental to distributed computing, a centralizedapproach for managing algorithm identifiers can create an artificialbottleneck or choking point, and entities seeking to impose regulationor control can effectively leverage the centralized design to restrictor prevent interoperability among distributed computing nodes.

Accordingly, in the illustrated embodiments of FIGS. 48 and 49, ablockchain is used to register a collection of distributed computingalgorithms (e.g., using self-sovereign algorithm identifiers). In someembodiments, for example, the blockchain may process an algorithmregistration request as a blockchain transaction, where the registrantselects a unique algorithm identifier and specifies the algorithmfunction. In various embodiments, the algorithm function may bespecified in human-readable form (e.g., as a natural languageexplanation or pseudocode), machine-readable form, and/ormachine-executable form. Moreover, as a condition or prerequisite toaccepting the algorithm registration, the particular algorithm may besubjected to various levels of “certification” by blockchain processingnodes. In this manner, an algorithm may be accepted with progressivelevels of assurance without altering the registered algorithmidentifier.

Accordingly, the described embodiments allow anyone that discovers auseful distributed computing algorithm to make that algorithm known andavailable to a large community. Blockchain networks, for example, arepresumed to be large in number and open to large communities of users.In this manner, members of the community can build distributed computingsystems without being hindered by bureaucratic roadblocks and oversight.As a result, the time between algorithm development and practicaldeployment can be minimized.

FIG. 48 illustrates an example embodiment of a distributed computingarchitecture 4800 with self-sovereign algorithm identification. In theillustrated embodiment, architecture 4800 includes fog networks A and B4810 a-b, along with a self-sovereign blockchain 4820 for registeringand identifying distributed computing algorithms 4430. In someembodiments, for example, architecture 4800 could be used to registerand/or identify algorithms used for visual fog computing.

As an example, if a useful distributed computing algorithm 4430 isinvented, discovered, and/or improved upon in a first fog network (e.g.,fog network A 4810 a), the first fog network may register the newalgorithm in a self-sovereign blockchain 4420 used for algorithmidentification. The blockchain processing nodes of the blockchain 4420may then progressively vet the algorithm in order to provideprogressively stronger assurances regarding its legitimacy (e.g., basedon the computational properties and outcome of the algorithm). Moreover,a second fog network (e.g., fog network B 4810 b) may subsequently benotified of the availability of the new algorithm, and may determinewhether the new algorithm has been adequately vetted (e.g., byconsulting the vetting status of the algorithm in the blockchain 4420).If the second fog network is satisfied with the vetting of the newalgorithm, the second fog network may agree to use the algorithm. Forexample, in some embodiments, after the algorithm has been adequatelyvetted, the first fog network and second fog network may agree to beginusing the new algorithm.

In some embodiments, the algorithm registration and vetting process mayinvolve: (1) registration of a self-sovereign algorithm identifier(SSAI); (2) peer-review of a human-readable description of thealgorithm; (3) machine analysis of a machine-readable representation ofthe algorithm (e.g., analysis by a logic processor to identify safebehavioral properties); and (4) execution of a machine-executableimplementation of the algorithm (e.g., execution in a sandboxenvironment used to analyze expected behavior). Moreover, once a certainthreshold (e.g., a majority) of blockchain processing nodes orevaluators achieve similar vetting results, the algorithm identity andits vetting criteria/results are recorded in a block of the blockchain4420.

FIG. 49 illustrates an example call flow 4900 for registering adistributed computing algorithm using a self-sovereign blockchain. Insome embodiments, for example, an algorithm may be registered using aself-sovereign blockchain to facilitate use of the algorithm across oneor more distributed or fog computing environments. Moreover, in someembodiments, the blockchain may leverage various levels of vetting toensure the algorithm behaves as expected, and verify that the algorithmidentifier is not already in use.

In the illustrated call flow 4900, for example, each blockchainprocessing node performs the following steps:

(1) receive transaction request from new device: TX_(n+1)={S1, “91E21”}, where S1=Sign_K_(alice)(“91E21”, “Human-readable-description”,“Machine-readable-description”, “Machine-executable-implementation”);

(2) optional algorithm vetting (e.g., peer-review of a human-readablealgorithm description, logical analysis of a machine-readable algorithmdescription/representation, sandbox execution of a machine-executablealgorithm form);

(3) compute hash H1=SHA256(“91E21”);

(4) search hash tree of transaction attributes, whereB_(x-poss)=Search(TxTree, H1);

(5) IF B_(x-poss)=“H1” THEN return ERROR_DUP_FOUND;

(6) ELSE IF B_(x-poss)=“ ” THEN add TX_(n+1) to the current block, whereCurrentBlock=[TX_(n+1), TX_(n), TX_(n−1), . . . , TX_(n−m)];

(7) compute new current block hash BH=SHA256([TX_(n+1), TX_(n),TX_(n−1), . . . , TX_(n−m)]);

(8) write BH to the blockchain at B_(curr-pos)(current position); and

(9) insert the tuple (H1, BH, B_(x-poss)) into TxTree.

Once the vetting process completes, the blockchain contains a vetted andregistered instance of the algorithm and its associated identifier. Inthis manner, distributed computing nodes may then begin using thealgorithm (e.g., based on the algorithm identifier and optionally itsmachine-readable and/or machine-executable forms).

Applications

The visual fog architecture and embodiments described throughout thisdisclosure can be used for a variety of large-scale visual computingapplications and use cases, such as digital security and surveillance,business automation and analytics (e.g., retail and enterprise),transportation (e.g., traffic monitoring, navigation, parking,infrastructure planning, security or amber alerts), education, videobroadcasting and playback, artificial intelligence, and so forth.

As an example, the described embodiments could be used to implementwearable cameras for first responders that are capable of automaticallydetecting events or emergency situations and performing certainresponsive measures, such as notifying the appropriate personnel,triggering recording of the event by related or nearby cameras, and soforth.

As another example, the described embodiments could be used to implementa digital surveillance and security (DSS) system with people search orfacial recognition capabilities across visual data streams from multipledifferent cameras, sensors, and/or locations.

As another example, the described embodiments could be used to implementa digital surveillance and security (DSS) system with license plateidentification and fraud detection capabilities (e.g., identifying a carwith a license plate that does not match the corresponding vehiclerecord, identifying multiple cars with same license plate, and soforth).

As another example, the described embodiments could be used to providecustomer insights and analytics (e.g., for retail shoppers), such as anintra-store shopper trip summary (e.g., a list of products ordepartments interacted with by a shopper), an inter-store shopper tripsummary (e.g., identifying repeat customers by differentiating betweennew and returning customers as they enter a store with a single ormultiple locations), and so forth.

Similarly, the described embodiments could be used to providevisualization of customer or shopper insights and analytics (e.g.,visualizing a graph representation of visual metadata for humanconsumption).

As another example, the described embodiments could be used to performautomated demographics identification in a privacy-preserving manner(e.g., using top-view cameras or sensors for demographic mapping ofgender, age, race, and so forth).

As another example, the described embodiments could be used to performheat mapping in retail stores or other brick-and-mortar environments togenerate a representation of the crowd (e.g., using top-view sensors orcameras and/or multi-modal crowd emotion heat mapping). In someembodiments, for example, heat mapping could be leveraged foroptimization of store layouts, among other examples.

As another example, the described embodiments could be used to implementmulti-modal real-time customer reviews. For example, customer reviewsand/or customer satisfaction information could be collected and analyzedin real-time using multi-sensory data, which can be translated intoquantitative customer-to-customer reviews for any products or in-storeactivities of a particular store or brick-and-mortar environment.

Similarly, the described embodiments could be used to implementmulti-modal retailer-shopper double review, which may focus oncollection and analysis of both product reviews from customers andcustomer reviews from retailers.

As another example, the described embodiments could be used forautomated customer satisfaction analysis. For example, visual data couldbe used to measure customer satisfaction at check-out based onnon-verbal communication or body language. In this manner, customersatisfaction can be automatically inferred without requiring manualcustomer feedback (e.g., via a button or survey).

As another example, the described embodiments could be used to monitorthe effectiveness of employee-customer interactions. For example, visualdata could be used to measure and track the effectiveness ofcommunication between customers and salespeople with respect to findingdesired products or items. In some embodiments, for example, visual datacould be used to track users within a store, identify customer-employeecontact and interactions, and monitor the employee and/or customerresponses.

As another example, the described embodiments could be used to providedynamic ambience environments by identifying contextual information(e.g., relationships or actions) within a group of people. For example,visual data could be used to identify individuals and their associatedcontextual information to determine whether they are part of the samegroup (e.g., based on physical proximity and/or corresponding movement),and if so, to identify various parameters or characteristics of thegroup (e.g., a family shopping together in a store).

As another example, the described embodiments could be used to implementdouble auction real-time bidding (RTB). In some embodiments, forexample, visual data could be used to implement multi-shopper,multi-bidder real-time bidding (RTB) for brick-and-mortar retailers.

As another example, the described embodiments could be used to monitorand detect changes to store layouts based on visual data and/or sensors.

As another example, the described embodiments could be used for roboticinventory tracking and logistics (e.g., using stationary and/or movingcameras to track inventory of retail stores, warehouses, offices, and soforth).

As another example, the described embodiments could be used for roboticequipment inspection (e.g., using computer vision technology to inspectthe safety and/or health of equipment in a factory, plant, warehouse,store, office, and so forth).

As another example, the described embodiments could be used to provideautomated tipping recommendations, for example, based on multi-sensoryinputs and/or visual data reflective of factors that typically impactcustomer tipping behavior.

As another example, the described embodiments could be used forworkplace automation, such as workplace quality control, employeemonitoring, and so forth. In some embodiments, for example, visual datacould be used to analyze employee emotions in order to improveproductivity.

As another example, the described embodiments could be used foreducation and/or automated learning (e.g., using visual data to analyzestudent behavior in the classroom or at home in order to provide furtherassistance when appropriate).

As another example, the described embodiments could be used for videoplayback, such as user-centric video rendering, focused replays, and soforth. For example, user-centric video rendering could be used toperform focused rendering on 360-degree video by analyzing what the useris focusing on, and performing no or low-resolution processing onportions of the video that are outside the focus area of the user (e.g.,for virtual-reality (VR) and/or augmented-reality (AR) applications). Asanother example, focused video replays could be used to automaticallyfocus the rendering of a video replay on an area of interest, such asthe portion of a sports replay where most players are located.

As another example, the described embodiments could be used to trainartificial intelligence systems. In some embodiments, for example,visual data could be used to automatically generate ground truthinformation that can be used to train artificial intelligence or machinelearning models, such as deep learning neural networks.

These examples are merely illustrative of the limitless universe ofvisual applications and use cases that can be implemented using thevisual fog architecture described throughout this disclosure.

The flowcharts and block diagrams in the FIGURES illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousaspects of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder or alternative orders, depending upon the functionality involved.It will also be noted that each block of the block diagrams and/orflowchart illustration, and combinations of blocks in the block diagramsand/or flowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts, orcombinations of special purpose hardware and computer instructions.

The foregoing disclosure outlines features of several embodiments sothat those skilled in the art may better understand various aspects ofthe present disclosure. Those skilled in the art should appreciate thatthey may readily use the present disclosure as a basis for designing ormodifying other processes and structures for carrying out the samepurposes and/or achieving the same advantages of the embodimentsintroduced herein. Those skilled in the art should also realize thatsuch equivalent constructions do not depart from the spirit and scope ofthe present disclosure, and that they may make various changes,substitutions, and alterations herein without departing from the spiritand scope of the present disclosure.

All or part of any hardware element disclosed herein may readily beprovided in a system-on-a-chip (SoC), including a central processingunit (CPU) package. An SoC represents an integrated circuit (IC) thatintegrates components of a computer or other electronic system into asingle chip. The SoC may contain digital, analog, mixed-signal, andradio frequency functions, all of which may be provided on a single chipsubstrate. Other embodiments may include a multi-chip-module (MCM), witha plurality of chips located within a single electronic package andconfigured to interact closely with each other through the electronicpackage. In various other embodiments, the computing functionalitiesdisclosed herein may be implemented in one or more silicon cores inApplication Specific Integrated Circuits (ASICs), Field ProgrammableGate Arrays (FPGAs), and other semiconductor chips.

As used throughout this specification, the term “processor” or“microprocessor” should be understood to include not only a traditionalmicroprocessor (such as Intel's® industry-leading x86 and x64architectures), but also graphics processors, matrix processors, and anyASIC, FPGA, microcontroller, digital signal processor (DSP),programmable logic device, programmable logic array (PLA), microcode,instruction set, emulated or virtual machine processor, or any similar“Turing-complete” device, combination of devices, or logic elements(hardware or software) that permit the execution of instructions.

Note also that in certain embodiments, some of the components may beomitted or consolidated. In a general sense, the arrangements depictedin the figures should be understood as logical divisions, whereas aphysical architecture may include various permutations, combinations,and/or hybrids of these elements. It is imperative to note thatcountless possible design configurations can be used to achieve theoperational objectives outlined herein. Accordingly, the associatedinfrastructure has a myriad of substitute arrangements, design choices,device possibilities, hardware configurations, software implementations,and equipment options.

In a general sense, any suitably-configured processor can executeinstructions associated with data or microcode to achieve the operationsdetailed herein. Any processor disclosed herein could transform anelement or an article (for example, data) from one state or thing toanother state or thing. In another example, some activities outlinedherein may be implemented with fixed logic or programmable logic (forexample, software and/or computer instructions executed by a processor)and the elements identified herein could be some type of a programmableprocessor, programmable digital logic (for example, a field programmablegate array (FPGA), an erasable programmable read only memory (EPROM), anelectrically erasable programmable read only memory (EEPROM)), an ASICthat includes digital logic, software, code, electronic instructions,flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or opticalcards, other types of machine-readable mediums suitable for storingelectronic instructions, or any suitable combination thereof.

In operation, a storage may store information in any suitable type oftangible, non-transitory storage medium (for example, random accessmemory (RAM), read only memory (ROM), field programmable gate array(FPGA), erasable programmable read only memory (EPROM), electricallyerasable programmable ROM (EEPROM), or microcode), software, hardware(for example, processor instructions or microcode), or in any othersuitable component, device, element, or object where appropriate andbased on particular needs. Furthermore, the information being tracked,sent, received, or stored in a processor could be provided in anydatabase, register, table, cache, queue, control list, or storagestructure, based on particular needs and implementations, all of whichcould be referenced in any suitable timeframe. Any of the memory orstorage elements disclosed herein should be construed as beingencompassed within the broad terms ‘memory’ and ‘storage,’ asappropriate. A non-transitory storage medium herein is expresslyintended to include any non-transitory special-purpose or programmablehardware configured to provide the disclosed operations, or to cause aprocessor to perform the disclosed operations. A non-transitory storagemedium also expressly includes a processor having stored thereonhardware-coded instructions, and optionally microcode instructions orsequences encoded in hardware, firmware, or software.

Computer program logic implementing all or part of the functionalitydescribed herein is embodied in various forms, including, but in no waylimited to, hardware description language, a source code form, acomputer executable form, machine instructions or microcode,programmable hardware, and various intermediate forms (for example,forms generated by an HDL processor, assembler, compiler, linker, orlocator). In an example, source code includes a series of computerprogram instructions implemented in various programming languages, suchas an object code, an assembly language, or a high-level language suchas OpenCL, FORTRAN, C, C++, JAVA, or HTML for use with various operatingsystems or operating environments, or in hardware description languagessuch as Spice, Verilog, and VHDL. The source code may define and usevarious data structures and communication messages. The source code maybe in a computer executable form (e.g., via an interpreter), or thesource code may be converted (e.g., via a translator, assembler, orcompiler) into a computer executable form, or converted to anintermediate form such as byte code. Where appropriate, any of theforegoing may be used to build or describe appropriate discrete orintegrated circuits, whether sequential, combinatorial, state machines,or otherwise.

In one example, any number of electrical circuits of the FIGURES may beimplemented on a board of an associated electronic device. The board canbe a general circuit board that can hold various components of theinternal electronic system of the electronic device and, further,provide connectors for other peripherals. More specifically, the boardcan provide the electrical connections by which the other components ofthe system can communicate electrically. Any suitable processor andmemory can be suitably coupled to the board based on particularconfiguration needs, processing demands, and computing designs. Othercomponents such as external storage, additional sensors, controllers foraudio/video display, and peripheral devices may be attached to the boardas plug-in cards, via cables, or integrated into the board itself. Inanother example, the electrical circuits of the FIGURES may beimplemented as stand-alone modules (e.g., a device with associatedcomponents and circuitry configured to perform a specific application orfunction) or implemented as plug-in modules into application specifichardware of electronic devices.

Note that with the numerous examples provided herein, interaction may bedescribed in terms of two, three, four, or more electrical components.However, this has been done for purposes of clarity and example only. Itshould be appreciated that the system can be consolidated orreconfigured in any suitable manner. Along similar design alternatives,any of the illustrated components, modules, and elements of the FIGURESmay be combined in various possible configurations, all of which arewithin the broad scope of this specification. In certain cases, it maybe easier to describe one or more of the functionalities of a given setof flows by only referencing a limited number of electrical elements. Itshould be appreciated that the electrical circuits of the FIGURES andits teachings are readily scalable and can accommodate a large number ofcomponents, as well as more complicated/sophisticated arrangements andconfigurations. Accordingly, the examples provided should not limit thescope or inhibit the broad teachings of the electrical circuits aspotentially applied to a myriad of other architectures.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims.

Example Implementations

The following examples pertain to embodiments described throughout thisdisclosure.

One or more embodiments may include an apparatus, comprising: aprocessor to: identify a workload comprising a plurality of tasks;generate a workload graph based on the workload, wherein the workloadgraph comprises information associated with the plurality of tasks;identify a device connectivity graph, wherein the device connectivitygraph comprises device connectivity information associated with aplurality of processing devices; identify a privacy policy associatedwith the workload; identify privacy level information associated withthe plurality of processing devices; identify a privacy constraint basedon the privacy policy and the privacy level information; and determine aworkload schedule, wherein the workload schedule comprises a mapping ofthe workload onto the plurality of processing devices, and wherein theworkload schedule is determined based on the privacy constraint, theworkload graph, and the device connectivity graph; and a communicationinterface to send the workload schedule to the plurality of processingdevices.

In one example embodiment of an apparatus, the processor to determinethe workload schedule is further to solve an integer linear programmingmodel based on the privacy constraint.

In one example embodiment of an apparatus, the plurality of tasks isassociated with processing sensor data from one or more sensors.

In one example embodiment of an apparatus, the one or more sensorscomprise one or more of: a camera; an infrared sensor; or a laser-basedsensor.

In one example embodiment of an apparatus, the sensor data comprisesvisual data.

In one example embodiment of an apparatus, the workload graph furthercomprises information associated with a plurality of task dependenciesamong the plurality of tasks.

In one example embodiment of an apparatus, the privacy policy comprisesa plurality of privacy requirements associated with the plurality oftask dependencies.

In one example embodiment of an apparatus, the device connectivityinformation comprises information associated with a plurality of deviceconnectivity links among the plurality of processing devices.

In one example embodiment of an apparatus, the privacy level informationcomprises a plurality of privacy levels associated with the plurality ofdevice connectivity links.

One or more embodiments may include a system, comprising: a plurality ofsensors to capture sensor data associated with an environment; aplurality of processing devices, wherein the plurality of processingdevices comprises a plurality of edge processing devices and a pluralityof cloud processing devices, and wherein the plurality of processingdevices is to: identify a workload, wherein the workload comprises aplurality of tasks associated with processing the sensor data capturedby the plurality of sensors; generate a workload graph based on theworkload, wherein the workload graph comprises information associatedwith the plurality of tasks; identify a device connectivity graph,wherein the device connectivity graph comprises device connectivityinformation associated with the plurality of processing devices;identify a privacy policy associated with the workload; identify privacylevel information associated with the plurality of processing devices;identify a privacy constraint based on the privacy policy and theprivacy level information; determine a workload schedule, wherein theworkload schedule comprises a mapping of the workload onto the pluralityof processing devices, and wherein the workload schedule is determinedbased on the privacy constraint, the workload graph, and the deviceconnectivity graph; and distribute the workload schedule to theplurality of processing devices.

In one example embodiment of a system, the plurality of processingdevices to determine the workload schedule is further to solve aninteger linear programming model based on the privacy constraint.

In one example embodiment of a system, the plurality of sensorscomprises one or more of: a camera; an infrared sensor; or a laser-basedsensor.

In one example embodiment of a system, the workload graph furthercomprises information associated with a plurality of task dependenciesamong the plurality of tasks.

In one example embodiment of a system, the privacy policy comprises aplurality of privacy requirements associated with the plurality of taskdependencies.

In one example embodiment of a system, the device connectivityinformation comprises information associated with a plurality of deviceconnectivity links among the plurality of processing devices.

In one example embodiment of a system, the privacy level informationcomprises a plurality of privacy levels associated with the plurality ofdevice connectivity links.

One or more embodiments may include at least one machine accessiblestorage medium having instructions stored thereon, wherein theinstructions, when executed on a machine, cause the machine to: identifya workload comprising a plurality of tasks; generate a workload graphbased on the workload, wherein the workload graph comprises informationassociated with the plurality of tasks; identify a device connectivitygraph, wherein the device connectivity graph comprises deviceconnectivity information associated with a plurality of processingdevices; identify a privacy policy associated with the workload;identify privacy level information associated with the plurality ofprocessing devices; identify a privacy constraint based on the privacypolicy and the privacy level information; determine a workload schedule,wherein the workload schedule comprises a mapping of the workload ontothe plurality of processing devices, and wherein the workload scheduleis determined based on the privacy constraint, the workload graph, andthe device connectivity graph; and distribute the workload schedule tothe plurality of processing devices.

In one example embodiment of a storage medium, the instructions thatcause the machine to determine the workload schedule further cause themachine to solve an integer linear programming model based on theprivacy constraint.

In one example embodiment of a storage medium, the plurality of tasks isassociated with processing sensor data from one or more sensors.

In one example embodiment of a storage medium: the workload graphfurther comprises information associated with a plurality of taskdependencies among the plurality of tasks; and the privacy policycomprises a plurality of privacy requirements associated with theplurality of task dependencies.

In one example embodiment of a storage medium: the device connectivityinformation comprises information associated with a plurality of deviceconnectivity links among the plurality of processing devices; and theprivacy level information comprises a plurality of privacy levelsassociated with the plurality of device connectivity links.

One or more embodiments may include a method, comprising: identifying aworkload, wherein the workload comprises a plurality of tasks associatedwith processing sensor data from one or more sensors; generating aworkload graph based on the workload, wherein the workload graphcomprises information associated with the plurality of tasks;identifying a device connectivity graph, wherein the device connectivitygraph comprises device connectivity information associated with aplurality of processing devices; identifying a privacy policy associatedwith the workload; identifying privacy level information associated withthe plurality of processing devices; identifying a privacy constraintbased on the privacy policy and the privacy level information;determining a workload schedule, wherein the workload schedule comprisesa mapping of the workload onto the plurality of processing devices, andwherein the workload schedule is determined based on the privacyconstraint, the workload graph, and the device connectivity graph; anddistributing the workload schedule to the plurality of processingdevices.

In one example embodiment of a method, determining the workload schedulecomprises solving an integer linear programming model based on theprivacy constraint.

In one example embodiment of a method: the workload graph furthercomprises information associated with a plurality of task dependenciesamong the plurality of tasks; and the privacy policy comprises aplurality of privacy requirements associated with the plurality of taskdependencies.

In one example embodiment of a method: the device connectivityinformation comprises information associated with a plurality of deviceconnectivity links among the plurality of processing devices; and theprivacy level information comprises a plurality of privacy levelsassociated with the plurality of device connectivity links.

1.-25. (canceled)
 26. A computing device to perform privacy-preservingworkload scheduling across a computing infrastructure, comprising:network interface circuitry to communicate over a network; andprocessing circuitry to: receive, via the network interface circuitry, arequest to schedule a workload for execution across the computinginfrastructure; access a privacy policy associated with the workload,wherein the privacy policy indicates a plurality of privacy requirementsfor execution of the workload; access a privacy level agreementassociated with the computing infrastructure, wherein the privacy levelagreement indicates a plurality of privacy levels provided across thecomputing infrastructure; determine, based at least in part on theprivacy policy and the privacy level agreement, a workload schedule forexecuting the workload, wherein the workload schedule assigns executionof the workload across a portion of the computing infrastructure; andsend, via the network interface circuitry, the workload schedule to theportion of the computing infrastructure assigned to execute theworkload.
 27. The computing device of claim 3, wherein: the workloadcomprises a plurality of tasks and a plurality of task dependenciesamong the plurality of tasks; and the computing infrastructure comprisesa plurality of processing devices and a plurality of device connectivitylinks among the plurality of processing devices.
 28. The computingdevice of claim 27, wherein: the plurality of privacy requirements arerequired across the plurality of task dependencies of the workload; andthe plurality of privacy levels are provided across the plurality ofdevice connectivity links of the computing infrastructure.
 29. Thecomputing device of claim 28, wherein the workload schedule assignsexecution of the plurality of tasks of the workload across a subset ofthe plurality of processing devices of the computing infrastructure. 30.The computing device of claim 29, wherein the workload schedule maps theplurality of task dependencies of the workload across a subset of theplurality of device connectivity links of the computing infrastructure.31. The computing device of claim 4, wherein the processing circuitry tosend, via the network interface circuitry, the workload schedule to theportion of the computing infrastructure assigned to execute the workloadis further to: send, via the network interface circuitry, the workloadschedule to the subset of the plurality of processing devices of thecomputing infrastructure assigned to execute the plurality of tasks ofthe workload.
 32. The computing device of claim 27, wherein at leastsome of the plurality of tasks of the workload are to process sensordata captured by one or more sensors.
 33. The computing device of claim32, wherein: the one or more sensors comprise one or more cameras; andthe sensor data comprises visual data captured by the one or morecameras.
 34. The computing device of claim 33, wherein at least some ofthe plurality of privacy requirements are associated with processing thevisual data captured by the one or more cameras.
 35. The computingdevice of claim 26, wherein the processing circuitry to determine, basedat least in part on the privacy policy and the privacy level agreement,the workload schedule for executing the workload is further to: solve aninteger linear programming model based on the privacy policy associatedwith the workload and the privacy level agreement associated with thecomputing infrastructure; and map the workload across the computinginfrastructure based on a solution to the integer linear programmingmodel.
 36. At least one non-transitory machine-readable storage mediumhaving instructions stored thereon, wherein the instructions, whenexecuted on processing circuitry, cause the processing circuitry to:receive, via network interface circuitry, a request to schedule aworkload for execution across a computing infrastructure; access aprivacy policy associated with the workload, wherein the privacy policyindicates a plurality of privacy requirements for execution of theworkload; access a privacy level agreement associated with the computinginfrastructure, wherein the privacy level agreement indicates aplurality of privacy levels provided across the computinginfrastructure; determine, based at least in part on the privacy policyand the privacy level agreement, a workload schedule for executing theworkload, wherein the workload schedule assigns execution of theworkload across a portion of the computing infrastructure; and send, viathe network interface circuitry, the workload schedule to the portion ofthe computing infrastructure assigned to execute the workload.
 37. Thestorage medium of claim 36, wherein: the workload comprises a pluralityof tasks and a plurality of task dependencies among the plurality oftasks; and the computing infrastructure comprises a plurality ofprocessing devices and a plurality of device connectivity links amongthe plurality of processing devices.
 38. The storage medium of claim 7,wherein: the plurality of privacy requirements are required across theplurality of task dependencies of the workload; and the plurality ofprivacy levels are provided across the plurality of device connectivitylinks of the computing infrastructure.
 39. The storage medium of claim38, wherein the workload schedule assigns execution of the plurality oftasks of the workload across a subset of the plurality of processingdevices of the computing infrastructure.
 40. The storage medium of claim39, wherein the workload schedule maps the plurality of taskdependencies of the workload across a subset of the plurality of deviceconnectivity links of the computing infrastructure.
 41. The storagemedium of claim 39, wherein the instructions that cause the processingcircuitry to send, via the network interface circuitry, the workloadschedule to the portion of the computing infrastructure assigned toexecute the workload further cause the processing circuitry to: send,via the network interface circuitry, the workload schedule to the subsetof the plurality of processing devices of the computing infrastructureassigned to execute the plurality of tasks of the workload.
 42. Thestorage medium of claim 8, wherein: at least some of the plurality oftasks of the workload are to process visual data captured by one or morecameras; and at least some of the plurality of privacy requirements areassociated with processing the visual data captured by the one or morecameras.
 43. The storage medium of claim 36, wherein the instructionsthat cause the processing circuitry to determine, based at least in parton the privacy policy and the privacy level agreement, the workloadschedule for executing the workload further cause the processingcircuitry to: solve an integer linear programming model based on theprivacy policy associated with the workload and the privacy levelagreement associated with the computing infrastructure; and map theworkload across the computing infrastructure based on a solution to theinteger linear programming model.
 44. A method of performingprivacy-preserving workload scheduling across a computinginfrastructure, comprising: receiving, via network interface circuitry,a request to schedule a workload for execution across the computinginfrastructure; accessing a privacy policy associated with the workload,wherein the privacy policy indicates a plurality of privacy requirementsfor execution of the workload; accessing a privacy level agreementassociated with the computing infrastructure, wherein the privacy levelagreement indicates a plurality of privacy levels provided across thecomputing infrastructure; determining, based at least in part on theprivacy policy and the privacy level agreement, a workload schedule forexecuting the workload, wherein the workload schedule assigns executionof the workload across a portion of the computing infrastructure; andsending, via the network interface circuitry, the workload schedule tothe portion of the computing infrastructure assigned to execute theworkload.
 45. The method of claim 44, wherein: the workload comprises aplurality of tasks and a plurality of task dependencies among theplurality of tasks; and the computing infrastructure comprises aplurality of processing devices and a plurality of device connectivitylinks among the plurality of processing devices.
 46. The method of claim45, wherein: the plurality of privacy requirements are required acrossthe plurality of task dependencies of the workload; and the plurality ofprivacy levels are provided across the plurality of device connectivitylinks of the computing infrastructure.
 47. The method of claim 46,wherein: the workload schedule assigns execution of the plurality oftasks of the workload across a subset of the plurality of processingdevices of the computing infrastructure; and the workload schedule mapsthe plurality of task dependencies of the workload across a subset ofthe plurality of device connectivity links of the computinginfrastructure.
 48. The method of claim 45, wherein: at least some ofthe plurality of tasks of the workload are to process visual datacaptured by one or more cameras; and at least some of the plurality ofprivacy requirements are associated with processing the visual datacaptured by the one or more cameras.
 49. The method of claim 11, whereindetermining, based at least in part on the privacy policy and theprivacy level agreement, the workload schedule for executing theworkload comprises: solving an integer linear programming model based onthe privacy policy associated with the workload and the privacy levelagreement associated with the computing infrastructure; and mapping theworkload across the computing infrastructure based on a solution to theinteger linear programming model.
 50. A system for performingprivacy-preserving workload scheduling across a computinginfrastructure, comprising: means for receiving a request to schedule aworkload for execution across the computing infrastructure; means foraccessing a privacy policy associated with the workload, wherein theprivacy policy indicates a plurality of privacy requirements forexecution of the workload; means for accessing a privacy level agreementassociated with the computing infrastructure, wherein the privacy levelagreement indicates a plurality of privacy levels provided across thecomputing infrastructure; means for determining, based at least in parton the privacy policy and the privacy level agreement, a workloadschedule for executing the workload, wherein the workload scheduleassigns execution of the workload across a portion of the computinginfrastructure; and means for sending the workload schedule to theportion of the computing infrastructure assigned to execute theworkload.